Das Problem mit traditionellen Code-Sicherheits-Scans

Static Application Security Testing, allgemein bekannt als SAST, ist seit mehr als zwei Jahrzehnten das dominierende Paradigma für automatisierte Code-Sicherheitsanalysen. Der Ansatz ist konzeptionell einfach: Quellcode ohne Ausführung analysieren und nach Mustern suchen, die bekannten Schwachstellensignaturen entsprechen. SQL-Abfragen, die aus Benutzereingaben zusammengesetzt werden, Speicherzuweisungen ohne Grenzprüfung, kryptografische Funktionen mit schwachen Parametern—SAST-Tools können diese Muster schnell über Codebasen beliebiger Größe finden.

Das Problem ist die Falschpositivrate. Reife Enterprise-Codebasen erhalten regelmäßig SAST-Berichte mit Tausenden markierten Elementen, von denen die Mehrheit entweder nicht ausnutzbare Code-Muster, geminderte Schwachstellen oder legitime Verwendungen markierter APIs darstellt. Sicherheitsingenieure verbringen enorme Zeitmengen mit der Triage dieser Berichte. Das Signal-Rausch-Verhältnis ist so schlecht, dass viele Organisationen SAST-Tools regelmäßig ausführen, aber eine institutionelle Toleranz für das Ignorieren großer Teile ihrer Ausgabe entwickelt haben.

Dies ist das Problem, das OpenAI sagt, es mit Codex Security lösen wollte—und der Grund, warum es sich entschied, keinen SAST-Bericht als Teil des Produkts einzubeziehen.

Constraint Reasoning als Alternative

Codex Security verwendet eine andere Methodik, die OpenAI als KI-gestütztes Constraint Reasoning und Validierung beschreibt. Anstatt musterabgleich gegen Schwachstellensignaturen vorzunehmen, versucht das System zu begründen, ob eine Schwachstelle im spezifischen Kontext, in dem sie auftritt, wirklich ausnutzbar ist.

Die Unterscheidung ist in der Praxis enorm wichtig. Ein SAST-Tool könnte jede Instanz einer bestimmten String-Formatierungsfunktion als potenzielle Format-String-Schwachstelle markieren, unabhängig davon, ob die Eingaben dieser Funktion tatsächlich von einem Angreifer beeinflusst werden können. Codex Security versucht, Datenflüsse zu verfolgen, Vertrauensgrenzen zu verstehen und auszuwerten, ob ein Angreifer mit realistischem Zugriff den problematischen Code-Pfad tatsächlich auslösen könnte.

Dieser Ansatz lehnt sich an formale Verifikation und Constraint-Satisfaction-Methoden aus der akademischen Sicherheitsforschung an, wendet aber KI-Begründung an, um die Mehrdeutigkeit und Komplexität realer Codebasen zu bewältigen, bei denen formale Methoden traditionell Schwierigkeiten hatten zu skalieren.

Weniger Befunde, höhere Konfidenz

Der Kompromiss bei diesem Ansatz ist, dass Codex Security Schwachstellen übersehen könnte, die SAST finden würde. OpenAI ist transparent über diese Einschränkung. Das System ist darauf ausgelegt, Präzision über Recall zu priorisieren: Die Schwachstellen, die es findet, sollen echt und ausnutzbar sein, auch wenn es echte Schwachstellen in der Codebasis gibt, die das System nicht identifiziert.

Für Sicherheitsteams, die in minderwertiger SAST-Ausgabe ertrinken, könnte dieser Kompromiss attraktiv sein. Ein kleinerer Satz hochgradig vertrauenswürdiger, umsetzbarer Befunde kann konsistent behoben werden, was messbare Verbesserungen der Sicherheitslage erzeugt. Ein großer Satz von Befunden, bei denen die Mehrheit Falschpositiv ist, führt zu Analyseparalyse und in der Praxis oft dazu, dass nichts behoben wird.

OpenAI argumentiert, dass das Entwicklererlebnis auch erheblich besser ist, wenn Befunde vertrauenswürdig sind. Ein Entwickler, der gelernt hat, dass 80 Prozent der Sicherheitstool-Befunde in seiner Codebasis Rauschen sind, wird daran gewöhnt, Sicherheitswarnungen zu ignorieren. Ein Tool, das fast immer richtig ist, trainiert ein anderes Verhalten: Nehmen Sie jeden Befund ernst und beheben Sie ihn.

Validierungs-Pipeline

Codex Security kombiniert das anfängliche Constraint Reasoning mit einem Validierungsschritt, der KI nutzt, um Proof-of-Concept-Testfälle zu generieren, die versuchen, die Schwachstelle tatsächlich in einer isolierten Umgebung auszulösen. Wenn das Modell des Systems, wie eine Schwachstelle ausgenutzt werden könnte, in einen funktionierenden Exploit umgewandelt werden kann—sogar einen harmlosen, der nur demonstriert, dass der Code-Pfad ausgeführt wird—erhöht sich die Konfidenz in den Befund erheblich.

Dieser Validierungsschritt ist rechnerisch teuer im Vergleich zu statischem Musterabgleich, was ein Grund ist, warum der Ansatz nicht universell unter Sicherheitstools verbreitet ist. Aber er stellt ein wichtiges Qualitätstor dar. Schwachstellen, die sowohl die Constraint-Reasoning-Phase als auch die Exploit-Validierungsphase überstehen, sind erheblich wahrscheinlicher, echte Sicherheitsrisiken darzustellen, als SAST-Befunde, die keiner ausführungsgestützten Verifikation unterzogen wurden.

Positionierung in der Sicherheitstool-Landschaft

Codex Security wird nicht als Ersatz für alle Sicherheitstools positioniert. OpenAI beschreibt es als komplementär zu Fuzzing, Penetrationstests und manueller Code-Überprüfung. Die These ist, dass für die spezifische Aufgabe der automatisierten Code-Analyse Reasoning-basierte Ansätze bessere Ergebnisse als signaturbasierte Ansätze für die Codebasen und Schwachstellenklassen erzielen können, bei denen die KI-Begründung reif genug ist, um zuverlässig zu sein.

Das Produkt setzt einen breiteren Trend in KI-gestütztem Sicherheits-Tooling fort, hin zu Systemen, die Code-Semantik anstelle nur von Syntax verstehen. Da KI-Modelle, die auf großen Code-Korpora trainiert wurden, immer fähiger werden, über Programmverhalten zu begründen, verengt sich die Lücke zwischen dem, was automatisierte Tools zuverlässig finden können, und dem, was erfahrene menschliche Sicherheitsforscher finden können—obwohl sie noch nicht geschlossen ist.

Dieser Artikel basiert auf Berichten von OpenAI. Lesen Sie den ursprünglichen Artikel.

Originally published on openai.com