KI beschleunigt die Fehlersuche, ersetzt aber keine Validierung von Schwachstellen

Sims beschreibt den Kern des Problems knapp: Ausgabe ist nicht dasselbe wie Evidenz. Ein generierter Bericht könne professionell wirken und dennoch keine verlässliche Aussage über Ausnutzbarkeit, Auswirkungen oder Risiko liefern. Gerade in der offensiven Sicherheitsprüfung sei nicht die Formulierung eines glaubwürdigen Berichts die eigentliche Hürde, sondern der Nachweis dessen, was technisch und im Zielsystem tatsächlich stimmt.

Warnzeichen seien bereits sichtbar. Bug-Bounty-Programme und Maintainer hätten mit einer Welle minderwertiger, KI-generierter Meldungen zu tun, die oft nur dünne Belege, vorlagenhafte Sprache und kaum sinnvolle Validierung enthielten. Bugcrowd habe dieses Muster öffentlich in seinen Richtlinien zu KI-generierten Einsendungen aufgegriffen und eine Klasse von Berichten beschrieben, die zwar ausgefeilt wirke, aber vor allem unnötige Triage-Arbeit verursache statt nützliche Sicherheitssignale zu liefern.

Nach Ansicht des Autors reicht das Problem über Bug-Bounty-Programme hinaus. Überall dort, wo KI Sicherheitsbefunde ohne ausreichendes menschliches Urteilsvermögen erzeuge, entstünden mehr Berichte, mehr Warnmeldungen und mehr Behauptungen. Ohne Validierung führe das nicht zu besserer Sicherheit, sondern lediglich zu längeren Warteschlangen. Das treffe auf Teams, die ohnehin schon mit Scanner-Ausgaben, Abhängigkeitswarnungen, Cloud-Konfigurationsproblemen und Compliance-Funden überlastet seien.

Ein belastbarer Befund müsse deshalb grundlegende Fragen klar beantworten: Was ist passiert? Wie ließ sich das Verhalten reproduzieren? Was kontrolliert ein Angreifer? Welche Grenze wurde überschritten? Und welche Auswirkung wurde konkret nachgewiesen? Fehlen diese Punkte, mag ein Bericht interessant sein, tauge aber noch nicht als Grundlage für Maßnahmen in der Entwicklung.

Besonders problematisch sei die Verwechslung eines verdächtigen Musters mit einer bestätigten Schwachstelle. KI sei gut darin zu erklären, warum etwas problematisch sein könnte. Sie könne etwa bei Benutzereingaben nahe einer Datenbankabfrage eine SQL-Injection vermuten, bei einem URL-Abruf SSRF nahelegen oder bei einer riskanten Programmierschnittstelle auf Remotecodeausführung schließen. Manchmal liege das Modell richtig, manchmal übersehe es aber die Bedingungen, die erst darüber entscheiden, ob ein Problem praktisch relevant ist.

Genau hier beginne laut Sims die eigentliche offensive Sicherheitsarbeit. Ein Tester müsse nachweisen, dass ein angreiferkontrollierter Eingabewert die gefährliche Operation tatsächlich erreicht. Ebenso müsse geklärt werden, ob Authentifizierung erforderlich ist, Autorisierung an anderer Stelle greift, eine anfällige Funktion überhaupt aktiviert ist, die produktive Konfiguration den Codepfad freigibt oder die Anwendung Eingaben normalisiert, kodiert, bereinigt oder verwirft, bevor sie sicherheitsrelevant werden. Ebenso entscheidend sei, ob wirklich eine Vertrauensgrenze überschritten werde oder nur ein interner Pfad ohne praktische Sicherheitsauswirkung betroffen sei.

Sims betont, dass Werkzeuge schon immer Teil der Arbeit waren, ihre Ausgaben allein aber nie ausreichten. Ein Webscanner könne einen Parameter markieren, der Eingaben zurückspiegelt. Ein statischer Analysator könne eine gefährliche Funktion kennzeichnen. Ein Fuzzer könne einen Absturz erzeugen. Ein Sprachmodell könne einen plausiblen Angriffspfad formulieren. In jedem Fall müsse jemand verstehen, was dieses Signal tatsächlich bedeutet.

Diese Fähigkeit entstehe meist durch praktische Erfahrung: Anfragen nachverfolgen, Quellcode lesen, Binärdateien rückentwickeln, Abstürze debuggen, Exploit-Code schreiben und Authentifizierungsabläufe aufbrechen. Daraus entstünden Mustererkennung und technisches Urteilsvermögen. Wer sich zu stark auf KI verlasse, riskiere laut Sims, genau diese Fähigkeiten zu verlernen. Das sei kein Argument gegen KI, sondern für menschliches Lernen.

Als sinnvollstes Einsatzmodell beschreibt der Autor eine klare Trennung zwischen Hinweisen und validierten Befunden. KI dürfe Kandidaten erzeugen, Testideen vorschlagen und Reproduktionen beschleunigen. Der Schritt vom Hinweis zum gemeldeten Finding müsse aber Belege erfordern. Gerade bei schwerwiegenden Einschätzungen sei das wichtig: Reflektierte Eingaben seien erst dann Cross-Site-Scripting, wenn Skriptausführung nachgewiesen ist. Ein URL-Abruf sei erst dann relevante SSRF, wenn sich ein Ziel erreichen lasse, das ein Angreifer nicht erreichen sollte. Und eine gefährliche Funktion sei erst dann Remotecodeausführung, wenn Erreichbarkeit, Kontrolle und Ausführung bewiesen sind.

Sims verweist zudem darauf, dass Befunde oft zu hoch eingestuft würden. Nicht selten erhalte ein Bericht einen CVSS-Wert von 9,8, obwohl es sich möglicherweise gar nicht um einen echten Befund handle. Gute Validierung verhindere dabei sowohl Unter- als auch Übermeldungen. Tenable habe kürzlich ebenfalls auf Schwierigkeiten in diesem Bereich hingewiesen, darunter auf kritische Kontextkombinationen, die häufig übersehen würden.

Das Ziel sei daher nicht, KI zu vermeiden. Sie sei zu nützlich dafür. Entscheidend sei vielmehr, sie so einzusetzen, dass sie offensive Tests stärke, statt die Menschen dahinter zu schwächen. Der Maßstab des Fachs bleibe unverändert: einen Fehler nachweisen, seine Erreichbarkeit belegen, die Auswirkung demonstrieren, das geschäftliche Risiko einordnen und zeigen, dass eine Korrektur wirkt.