Das Szenario ist in der Security-Community wohlbekannt: Ein Unternehmen investiert in ein modernes automatisiertes Penetrationstesting-Tool. Der erste Test liefert spektakuläre Ergebnisse – das Dashboard leuchtet auf mit kritischen Befunden, unbekannten Lateralbewegungspfaden und veralteten Service-Accounts. Das Security-Team jubelt, der CISO ist erleichtert. Die “menschliche Komponente” von Sicherheit scheint endlich automatisiert zu sein.
Doch die Euphorie währt nicht lange. Bereits beim vierten oder fünften Durchlauf versiegen die neuen Erkenntnisse. Das Tool meldet wieder dieselben Probleme, das ehemals glänzende Dashboard wird zur Lärmquelle. Was hier passiert, nennen Experten die “Validierungslücke” – der wachsende Abstand zwischen dem, was tatsächlich validiert wird, und dem, was als validiert berichtet wird.
Die strukturelle Grenze der Automatisierung
Dieser Trend ist nicht anekdotisch. Sicherheitspraktiker sprechen vom “Proof-of-Concept Cliff”: dem steilen Abfall bei neuen Erkenntnissen, sobald das Tool seinen fixen Umfang ausgeschöpft hat. Das ist kein Abstimmungsproblem – es ist eine architektonische Limitation.
Automatisierte Pentests liefern ihre besten Ergebnisse beim ersten Durchlauf. Danach sind exploitable Pfade innerhalb des definierten Umfangs schnell aufgebraucht. Das bedeutet aber nicht, dass die Umgebung sicher ist – sondern nur, dass das Tool an seine Grenzen gestoßen ist, während tiefere Probleme ungeprüft bleiben.
Dies führt zu einer kritischen Erkenntnis: Automatisierte Penetrationstests und Breach-and-Attack-Simulation (BAS) sind fundamental unterschiedliche Ansätze. Während Pentests Angriffspfade kartografieren, validiert BAS, ob Ihre tatsächlichen Sicherheitskontrollen funktionieren.
Sechs Validierungsflächen, kaum abgedeckt
Experten identifizieren sechs kritische Sicherheitsflächen: Netzwerk- und Endpunkt-Kontrollen, Detektions- und Response-Stacks, Infrastruktur- und Applikations-Angriffspfade, Identitäts- und Privilege-Management, Cloud- und Container-Umgebungen sowie KI und neu Technologien.
Automatisierte Pentests decken diese Flächen dramatisch unvollständig ab. Sie zeigen, dass ein Exploit funktioniert, bestätigen aber nicht, ob die Firewall, das EDR-System oder das SIEM tatsächlich aktiv blocken oder alarmieren würde. Detection-Coverage wird angenommen, nicht gemessen. Bei Cloud- und KI-Systemen bleibt vieles völlig im Dunkeln.
Was Unternehmen tun sollten
Deutsche Organisationen sollten bei Vendor-Gesprächen drei Fragen stellen: Welche der sechs Validierungsflächen deckt das Tool ab und in welchem Umfang? Wie unterscheidet die Plattform ausnutzbare Schwachstellen von theoretischen – basierend auf Live-Performance-Daten? Wie normalisiert das Tool Erkenntnisse aus anderen Security-Systemen in eine einheitliche, deduplizierte Prioritätenliste?
Die unbequeme Wahrheit: Viele moderne Sicherheitslücken entstehen genau in den Bereichen, die automatisierte Pentests nicht validieren.