Ihr Schwachstellenscanner meldet: alles grün. Ihr Angreifer meldet: ich bin drin. Dieses Szenario ist
keine Theorie, sondern Alltag in vielen Unternehmen, die Pentesting mit dem Durchlaufen
automatisierter Schwachstellenscanner gleichsetzen. Die Dashboards sind grün, die letzten Scans
liefen ohne „Critical Findings“ durch, also alles sicher, oder? In der Praxis ist genau diese
Scheinsicherheit eines der größten Risiken. Automatisierte Scans übersehen systematisch bestimmte
Schwachstellenarten und Konstellationen, insbesondere solche, die sich aus Geschäftslogik, Kontext
oder der Kombination mehrerer Einzelfindings ergeben. Die Konsequenzen für Ihr Geschäft können
massiv sein.
Scanner sind unverzichtbar — aber sie lösen ein anderes Problem
Zuerst die gute Nachricht: Scanner haben ihren festen Platz in jedem Security-Setup. Sie finden
bekannte Schwachstellen mit definierten Signaturen wie XSS, SQL-Injection und veraltete
Komponenten, und sie lassen sich nahtlos in CI/CD-Pipelines integrieren, um wiederholbare
Prüfungen zu automatisieren. Für diese Aufgaben sind sie schnell, zuverlässig und kosteneffizient.
Das Problem entsteht, wenn aus „Scanner im Einsatz“ automatisch „System ist sicher“ abgeleitet
wird. Scanner beantworten vor allem die Frage: Welche bekannten Standardlücken gibt es in meinem
System? Sie beantworten aber nicht die entscheidende Frage: Welches konkrete Risiko entsteht aus
diesen Lücken in meinem Geschäfts- und Infrastrukturkontext?
Das Ergebnis: scheinbare Sicherheit mit echten Lücken an den entscheidenden Stellen.
Die blinden Flecken der Automatisierung
Drei Schwachstellen-Klassen werden von automatisierten Tools in der Praxis nur unzureichend
erfasst.
Kontextblindheit. Ein „Medium“-CVSS-Score direkt neben Ihrer Kundendatenbank ist nicht
automatisch ein mittleres Risiko. Im konkreten Systemkontext kann daraus ein kritischer Befund
werden, etwa wenn über diese Lücke Bewegungsprofile, Finanzdaten oder Gesundheitsinformationen
zugänglich werden. Ein Scanner kennt Ihre Infrastruktur, Ihre Datenflüsse und Ihre tatsächlichen
Kronjuwelen nicht. Ein erfahrener Penetrationstester schon.
Fehlende Angriffsketten. Scanner prüfen Schwachstellen isoliert: ein Finding hier, ein Finding dort,
jeweils für sich genommen vielleicht „Low“ oder „Medium“. Angreifer denken anders. Sie verknüpfen
zwei vermeintlich harmlose Einzellücken zu einer Angriffskette, die zum vollständigen Systemzugang
führt. Diese kreative Kombination aus Schwachstellen, Fehlkonfigurationen und Prozessfehlern
entzieht sich der typischen Automatisierungslogik.
Fehler in Custom-Code und Geschäftslogik. Alles, was nicht in einer CVE-Datenbank steht, ist für
klassische Scanner praktisch unsichtbar. Individuelle Implementierungen, proprietäre Prozesse,
maßgeschneiderte Integrationen, komplexe Berechtigungslogiken: genau hier beginnt manuelles
Testen. Typische Beispiele: fehlerhafte Autorisierungsprüfungen, Logikfehler im Zahlungs- oder
Freigabeprozess, Missbrauchsmöglichkeiten durch ungewöhnliche User-Flows.
Der menschliche Faktor: Echte Angreifer scannen nicht
Echte Angreifer starten keinen „Weekly Scan“. Sie analysieren Ihr Geschäftsmodell. Sie wollen
verstehen, welche Assets wirklich schützenswert sind: Kundendaten, geistiges Eigentum, Zugänge zu
Partner-Systemen. Genau darauf richten sie ihre Aktivitäten gezielt aus.
Erfahrene Penetrationstester arbeiten deshalb bewusst anders als automatisierte Tools:
- Sie denken in Geschäftsprozessen statt in reinen CVEs.
- Sie suchen nach ungewöhnlichen Kombinationen und unerwarteten Wegen durchs System, statt nur bekannte Payloads auszuführen.
- Sie liefern belastbare Proof-of-Concepts statt theoretischer Warnungen, inklusive konkreter, im System nachstellbarer Angriffsszenarien.
- Sie übersetzen technische Befunde in verständliche Geschäftsrisiken für Entscheider und in umsetzbare Maßnahmen für Entwicklerteams.
So entsteht aus einer langen Liste technischer Findings ein priorisierter Maßnahmenplan, der sich an
tatsächlichem Risiko und Business-Impact orientiert, nicht an der Reihenfolge im Scan-Report.
Vom Jahres-Pentest zu kontinuierlichen Mikrotests
Viele Organisationen arbeiten noch mit dem klassischen Modell: ein umfangreicher Jahres-Pentest
als Pflichtübung, der Bericht landet auf dem Schreibtisch, die nächste Prüfung ist in zwölf Monaten
geplant. In der Zwischenzeit entwickeln sich Systeme, Architekturen und Bedrohungslage täglich
weiter. Die eigentlichen Risiken entstehen zwischen den Terminen.
Ein moderner Application-Security-Ansatz bedeutet deshalb:
- Gezielte Prüfungen bei relevanten Änderungen statt pauschaler Jahrestests
- Security als fester Bestandteil agiler Sprints
- Menschliche Expertise dort einsetzen, wo Automatisierung an ihre Grenzen stößt
Das Ergebnis: Sicherheit, die mit der Entwicklung Schritt hält und nicht als Bremsklotz, sondern als
Enabler für schnelle, stabile Releases wahrgenommen wird
Fünf klare Auslöser für manuelle Pentests
Wann sollten Unternehmen bewusst auf menschliche Pentester setzen, zusätzlich zu ihren Scannern?
In der Praxis haben sich fünf Trigger-Kriterien bewährt:
- Änderungen an Authentifizierungs- oder Autorisierungslogik: ein besonders häufiger
Einstiegspunkt realer Angriffe - Neue externe Schnittstellen — APIs, Drittanbieter-Integrationen, Zahlungsprozesse
- Kritische Releases und Compliance-Audits, z.B. NIS2, ISO 27001, DSGVO
- Größere Architekturänderungen oder Migrationsprojekte — Cloud-Migrationen,
Plattformwechsel, neue Authentifizierungsarchitekturen - Wiederholte „Medium“-Findings aus Scans, bei denen unklar ist, welche im konkreten Kontext
tatsächlich kritisch sind
Wer diese Ereignisse systematisch identifiziert und mit Mikrotests verknüpft, reduziert das Risiko,
dass aus vermeintlichen Nice-to-have-Fixes echte Sicherheitsvorfälle werden.
Sicherheit messbar machen: Die Kennzahlen, die wirklich zählen
Auch im Security-Umfeld wird gern mit Zahlen gearbeitet, die auf den ersten Blick professionell
wirken, aber wenig über das tatsächliche Risiko aussagen. Ein typisches Beispiel: die reine Anzahl
behobener Scanner-Warnungen.
Aussagekräftiger sind Kennzahlen, die sich an Wirkung und Geschwindigkeit orientieren:
- MTTR kritischer Findings: Wie schnell werden wirklich kritische Schwachstellen geschlossen?
- Schwachstellendichte im Zeitverlauf: Wie entwickelt sich die Zahl sicherheitsrelevanter Fehler im Code?
- Deployment-Frequenz ohne Security-Rollbacks: Unterstützt Security den Entwicklungsprozess oder blockiert sie ihn?
- Anteil fristgerecht geschlossener kritischer Findings: Wie viele kritische Befunde werden innerhalb von 30 Tagen behoben?
Solche Metriken steuern Security als kontinuierlichen Verbesserungsprozess und machen die
Wirksamkeit von Maßnahmen messbar, statt nur das Abarbeiten von Findings zu dokumentieren.
Fazit: Automatisierung ist der Anfang — nicht das Ende
Scanner liefern die Basis. Sie sind ideal, um bekannte Schwachstellen schnell und regelmäßig
aufzuspüren und in moderne Entwicklungsprozesse zu integrieren. Die Sicherheit, die wirklich zählt,
entsteht jedoch erst durch das Zusammenspiel aus Automatisierung und menschlicher Expertise.
Menschliche Pentester ergänzen Ihre Tools um Kontext, Kreativität und Nachvollziehbarkeit. Sie
denken wie Angreifer, sprechen die Sprache des Business und helfen Ihren Teams, dort zu investieren,
wo ein echter Sicherheits- und Stabilitätsgewinn entsteht. Wer diese Kombination etabliert, verlässt
sich nicht auf „alles grün“, sondern weiß, warum das System hält, wenn der Angreifer tatsächlich vor
der Tür steht.
Mehr zu unserem Pentest-Ansatz: pen-sec.de/pentest