Warum bleiben Schwachstellen in Pentests oft unentdeckt?

In meiner Arbeit als IT-Security-Berater habe ich zahlreiche Pentests durchgeführt – und dabei immer wieder neue Schwachstellen gefunden, selbst in Anwendungen und Systemen, die bereits mehrfach getestet worden waren. Diese Erfahrung hat mir gezeigt: Auch erfahrene Teams und solide Prozesse übersehen Schwachstellen. In einem Kundenprojekt zur Optimierung von Pentest-Prozessen habe ich kürzlich darüber nachgedacht, woran das eigentlich liegt. Hier sind die Punkte, die mir dazu in den Sinn gekommen sind – und ich bin gespannt auf eure Erfahrungen und Einschätzungen.

Die häufigsten Ursachen

Zeitliche Einschränkung. Ein typischer Pentest hat ein klar begrenztes Zeitfenster. Reicht dieses nicht aus, können nicht alle potenziellen Angriffspunkte umfassend geprüft werden – besonders bei komplexen Systemen oder weitläufigen Netzwerken. Ein echter Angreifer hat dieses Zeitlimit nicht.
Unvollständige Informationen. Erhalten Tester nicht alle relevanten Informationen über das Zielsystem – Architektur, Zugänge, fachliche Logik –, bleiben wichtige Schwachstellen leicht unentdeckt. In großen, gewachsenen Umgebungen ist das ein besonders häufiges Problem.
Begrenzter oder falsch gesetzter Scope. Was außerhalb des Scopes liegt, wird nicht getestet – ein Angreifer hält sich aber nicht an Scope-Grenzen. Wird der Untersuchungsbereich zu eng gefasst oder eine vermeintlich nebensächliche Komponente ausgeklammert, entsteht genau dort ein blinder Fleck, der in der Praxis zum Einfallstor wird.
Menschlicher Faktor. Selbst die besten Sicherheitsexperten machen Fehler. Verschiedene Tester bringen unterschiedliche Erfahrungen und Schwerpunkte mit, weshalb bestimmte Schwachstellen übersehen werden können – vor allem, wenn sie untypisch oder schwer erkennbar sind.
Grenzen automatisierter Tools. Automatisierte Werkzeuge sind nützlich, aber nicht unfehlbar. Sie erkennen meist nur bekannte Muster und übersehen komplexere, kontextabhängige Angriffsvektoren. Ein Scan ersetzt kein manuelles, kreatives Testen.
Business-Logik-Schwachstellen. Fehler in der Anwendungslogik – etwa die Möglichkeit, einen Bezahlvorgang zu umgehen oder auf fremde Daten zuzugreifen – verstoßen gegen keine technische Regel und tauchen in keiner Signaturdatenbank auf. Sie zu finden erfordert ein echtes Verständnis dafür, wie die Anwendung eigentlich funktionieren soll – genau das, wofür unter Zeitdruck oft die Tiefe fehlt.
Eine Momentaufnahme in einer dynamischen Bedrohungslage. Ein Pentest beschreibt den Sicherheitszustand zu einem bestimmten Zeitpunkt. Schon am nächsten Tag kann ein Deployment neue Lücken einführen, und die Bedrohungslandschaft entwickelt sich ohnehin laufend weiter: Angriffsmethoden, die während des Tests noch unbekannt waren, sind kurz darauf Realität.
Nicht repräsentative Testumgebung. Unterscheidet sich die Testumgebung von der Produktion – andere Konfiguration, andere Daten, andere Integrationen –, sind bestimmte Schwachstellen schlicht nicht sichtbar. Getestet wird dann ein System, das es so im Echtbetrieb gar nicht gibt.
Schwachstellen in Drittanbieter-Komponenten. Anwendungen nutzen häufig Bibliotheken und Erweiterungen von Drittanbietern, die eigene Schwachstellen mitbringen. Sind diese zum Testzeitpunkt noch nicht öffentlich bekannt, bleiben sie unentdeckt – obwohl sie später zum Einfallstor werden können.

Vorbereitung entscheidet

Pentests sind ein zentraler Baustein jeder Sicherheitsstrategie – aber für sich allein reichen sie nicht aus. Die Qualität eines Pentests steht und fällt mit zwei Dingen: der Qualität der Vorbereitung und der Erfahrung der Person, die testet. Aus diesem Grund sind gut strukturierte Scoping- und Kickoff-Gespräche aus meiner Sicht kein Beiwerk, sondern essenziell. Sie entscheiden darüber, ob ein Test die richtigen Fragen stellt – oder an den eigentlich relevanten Risiken vorbeigeht.

Der wirkungsvollste Teil dieser Vorbereitung ist meiner Erfahrung nach ein vorgelagertes Threat Modeling. Werden die relevanten Bedrohungen und Angriffspfade vorab identifiziert und priorisiert, weiß der Test von Anfang an, wo er in die Tiefe gehen muss. Genau dadurch werden mehrere der oben genannten Ursachen von vornherein entschärft – ein zu eng gefasster Scope, fehlende Informationen und Zeit, die an der falschen Stelle investiert wird. (Mehr dazu in meinem Beitrag zum Threat Modeling vor dem Pentest.)

Wie ich arbeite

Genau hier setzt mein Ansatz bei HSEC.Consulting an: Ihr habt über den gesamten Projektverlauf einen einzigen, direkten Ansprechpartner. Wer den Scope mit euch abstimmt, ist auch derjenige, der testet – es geht also kein Detail aus dem Scoping- oder Kickoff-Gespräch in der Übergabe zwischen Vertrieb, Projektmanagement und Testteam verloren. Genau an dieser Übergabe geht in größeren Strukturen erfahrungsgemäß wertvoller Kontext verloren.

Kombiniert mit einer strukturierten, methodischen Vorgehensweise und Zertifizierungen wie OSCP und CISSP bedeutet das einen Pentest, der auf Tiefe und Kontext setzt statt auf abgehakte Checklisten.

Und weil keine Liste je vollständig ist: Welche Gründe würdet ihr ergänzen? Ich freue mich über euren Input.

#Pentesting #ITSecurity #CyberSecurity #VulnerabilityManagement