Dabirsiaghi beschreibt die aktuelle Lage in der Anwendungssicherheit als unbefriedigend: Bestehende Verfahren zur Priorisierung lieferten zu viele Fehlalarme, setzten falsche Schwerpunkte und berücksichtigten die Erreichbarkeit von Code zu wenig. Große Sprachmodelle hätten daran bislang kaum etwas geändert.

Als Beispiel nennt er automatisierte Aktualisierungen über Dependabot. Unternehmen könnten damit fortlaufend ihre Abhängigkeiten aktualisieren, würden dann aber täglich mit einer Flut von Pull Requests und entsprechendem Aufwand bei Build-Minuten konfrontiert. Die Alternative sei, jede gemeldete Schwachstelle manuell zu prüfen, um jene rund 8 Prozent zu finden, die tatsächlich relevant seien. Für diese Skalierung fehle es den meisten Unternehmen laut Dabirsiaghi an Personal.

Gleichzeitig wächst der Druck auf AppSec-Teams. Das Forum of Incident Response and Security Teams, kurz FIRST, schätzt, dass die Zahl der Probleme mit einer Common Vulnerabilities and Exposures-Kennung in diesem Jahr um 50 Prozent steigen wird. Microsoft verzeichnet laut dem Bericht zugleich Rekordvolumina bei Patch Tuesday. Die neueren KI-Modelle hätten sich dabei nicht als deutlich bessere Werkzeuge zur Schwachstellensuche erwiesen; sie arbeiteten oft langsamer und verursachten höhere Kosten als etablierte Tools. Selbst aktuelle Modelle wie Anthropic Mythos, die Schwachstellen gut finden könnten, erforderten weiterhin umfangreiche menschliche Kontrolle.

Der Kern des Problems liegt Dabirsiaghi zufolge im fehlenden Kontext. Große Sprachmodelle und fortgeschrittene KI-Werkzeuge würden noch immer erst lernen, wie Schwachstellen richtig zu analysieren sind. Selbst stark auf Entwickler ausgerichtete Modelle blieben im Vergleich zu spezialisierten Scan-Werkzeugen Generalisten. Damit sie in der Praxis nützlich werden, müssten Unternehmen den Modellen umfangreiche Informationen über ihre Software und ihre Bereitstellungsumgebungen liefern und zudem die passende technische Einbettung, also ein geeignetes Werkzeuggerüst, schaffen.

Ohne diese Einbettung drohe eine Überkorrektur. Dabirsiaghi warnt, dass ein Modell schlicht eine angebliche Schwachstelle an einer bestimmten Zeile melde und sie behebe, auch wenn der Befund gar nicht real sei. Das könne Qualität, Leistung und Sicherheit einer Anwendung verschlechtern. Zu viel unnötige Behebung führe außerdem zu niedrigen Merge-Raten und geringem Vertrauen in die Ergebnisse.

Für eine belastbare Triage seien deshalb drei Kontextarten nötig: organisatorischer Kontext, technischer Kontext und der weitere Code-Kontext. Dabirsiaghi illustriert das am Einsatz von MD5. Dessen Verwendung werde in Anwendungen oft standardmäßig mit mittlerer Schwere bewertet. Tatsächlich könne derselbe Fund entweder hochkritisch sein, wenn MD5 zum Hashen von Passwörtern oder Geheimnissen verwendet werde, oder niedrig beziehungsweise ein Fehlalarm, wenn es in einem nicht sicherheitsrelevanten Zusammenhang nur um Kollisionsresistenz gehe.

Ein weiterer zentraler Hebel ist für ihn die Erreichbarkeit. Unabhängig davon, mit welcher Methode sie gemessen werde, reduziere sie fast immer den Umfang des tatsächlich relevanten Codes deutlich. Eine Studie habe ergeben, dass 62 Prozent der Open-Source-Bibliotheken zur Laufzeit nie genutzt würden. Eine andere kam zu dem Ergebnis, dass von den 71 Prozent Open-Source-Anteil in Java-Code nur 12 Prozent tatsächlich verwendet werden.

Hinzu kommt ein praktisches Problem bei LLMs: Ohne unterstützende Funktionen und ein geeignetes Gerüst fielen Scan-Ergebnisse nicht deterministisch aus. Nach Dabirsiaghi könne dasselbe Modell bei identischer Faktenlage einmal einen Fehlalarm und beim nächsten Lauf einen echten Treffer melden. Genau diese Widersprüchlichkeit wolle er in seiner Black-Hat-Session „Jenseits der Erkennung: Was wir beim Testen jedes KI-Ansatzes zur Klassifizierung von Schwachstellen gelernt haben“ mit Testergebnissen und Empfehlungen zur Verbesserung von Code-Scans und Klassifizierung aufgreifen.