Der Kern des Arguments liegt im unterschiedlichen Vorgehen beider Ansätze. Automatisierte Penetrationstests sind nach Darstellung von Picus „richtungsgebunden": Sie verketten Schwachstellen und Fehlkonfigurationen so, wie es ein echter Angreifer täte, und legen damit komplexe Angriffspfade offen – etwa Kerberoasting im Active Directory oder eine Rechteausweitung bis zum Domänenadministrator-Konto. Breach and Attack Simulation dagegen verkettet nicht, sondern führt Tausende unabhängiger, atomarer Simulationen aus. Jede Technik läuft eigenständig: Ein über DNS blockierter Exfiltrationstest verhindert nicht den anschließenden Test über HTTPS, und eine gescheiterte Technik für seitliche Bewegung hindert das Werkzeug nicht daran, 19 weitere zu prüfen.
Daraus leitet der Beitrag zwei verschiedene Fragestellungen ab. BAS fragt, ob Firewalls, EDR, WAF und SIEM über das gesamte MITRE-ATT&CK-Rahmenwerk hinweg ihre Aufgabe tatsächlich erfüllen – es misst also die Wirksamkeit der Abwehrmaßnahmen. Automatisierte Pentests fragen, ob ein Angreifer mit bekannten Exploits von Punkt A zu Punkt B gelangt. Das eine prüft die Stärke der einzelnen Schutzschilde, das andere die Reichweite eines Angreifers trotz dieser Schilde.
Hacioglu wendet sich gegen die von einigen Anbietern vertretene These, automatisierte Pentests könnten und sollten BAS ersetzen. Das sei kein Fortschritt, sondern eine als Vereinfachung verkaufte Rückentwicklung der Abdeckung. Wer BAS-Bewertungen durch automatisierte Pentests ersetze, höre auf, seine Präventions- und Erkennungsschicht zu validieren: Man wisse vielleicht, dass ein bestimmter Exploit die Datenbank nicht erreicht, habe aber keinerlei Einblick, ob das EDR bei einer anderen, nicht-exploitbasierten Technik überhaupt reagieren würde.
Der Beitrag führt sechs Validierungsflächen an, von denen automatisierte Pentests keine vollständig abdecke – „0 von 6". Bei Netzwerk- und Endpunkt-Kontrollen würden Exploit-Pfade zwar erkannt, doch bleibe unbestätigt, ob Firewall, WAF, IPS, DLP oder EDR tatsächlich blockieren. Die Erkennungs- und Reaktionsschicht bleibe unsichtbar, weil das Tool als Angreifer agiere und den Verteidiger nicht beobachten könne. Hinzu kommen Infrastruktur- und Anwendungspfade, Identität und Rechtevergabe (Active Directory, IAM, Privilegiengrenzen), Cloud- und Container-Umgebungen mit driftenden Kubernetes-Richtlinien sowie KI-Technologien, deren Schutzmechanismen gegen Jailbreaks, Prompt Injection und Manipulation ungeprüft blieben.
Picus stellt dem seine eigene Plattform gegenüber, die theoretische CVEs gegen die reale Leistung der Sicherheitskontrollen abgleicht. Damit lasse sich der Anteil fälschlich als hoch oder kritisch eingestufter Funde – über 60 Prozent – auf die etwa 10 Prozent reduzieren, die wirklich ausnutzbar sind; die übertriebene Dringlichkeit sinke so um mehr als 80 Prozent.
Abschließend nennt der Beitrag drei Diagnosefragen für Anbietergespräche: Welche der sechs Validierungsflächen deckt das Werkzeug in welchem Umfang ab? Wie unterscheidet die Plattform ausnutzbare von theoretischen Schwachstellen anhand realer Kontrolldaten? Und wie führt sie Funde aus anderen Tools zu einer einzigen, entdoppelten und priorisierten Liste zusammen? Der Beitrag verweist auf den Praktikerleitfaden „The Validation Gap: What Automated Pentesting Alone Cannot See".