Warum Codex Security keinen SAST-Bericht enthält

Seit Jahrzehnten zählt das Static Application Security Testing (SAST) zu den effektivsten Methoden, mit denen Sicherheitsteams Code-Reviews im großen Stil durchführen können. 

Als wir Codex Security entwickelt haben, haben wir jedoch eine bewusste Designentscheidung getroffen: Wir haben nicht den Import eines statischen Analysebericht als Anfangspunkt gesetzt und den Agenten dann gebeten, ihn zu triagieren. Wir haben das System so konzipiert, dass es beim Repository selbst beginnt – seiner Architektur, seinen Vertrauensgrenzen und seinem beabsichtigten Verhalten – und dass es das, was es findet, validiert, bevor es einen Menschen bittet, Zeit darauf zu verwenden. 

Der Grund ist einfach: Die schwierigsten Schwachstellen sind meist keine Datenflussprobleme. Sie treten auf, wenn Code scheinbar eine Sicherheitsprüfung erzwingt, diese Prüfung aber die Eigenschaft, auf die sich das System verlässt, nicht wirklich garantiert. Mit anderen Worten: Die Herausforderung besteht nicht nur darin, nachzuverfolgen, wie Daten durch ein Programm fließen – es geht darum festzustellen, ob die Abwehrmaßnahmen im Code wirklich funktionieren.

SAST wird oft als eine saubere Pipeline dargestellt: eine Quelle nicht vertrauenswürdiger Eingaben identifizieren, Daten durch das Programm verfolgen und Fälle markieren, in denen diese Daten ohne Bereinigung eine sensitive Schwachstelle erreichen. Es ist ein elegantes Modell, und es deckt viele echte Fehler ab.

In der Praxis muss SAST Annäherungen vornehmen, um im großen Maßstab eingesetzt werden zu können – insbesondere in realen Codebasen mit Indirektion, dynamischem Dispatch, Callbacks, Reflection und framework-lastigem Control Flow. Diese Näherungen sind keine Kritik an SAST – sie spiegeln die Realität wider, wenn versucht wird, Schlussfolgerungen über Code zu ziehen, ohne ihn auszuführen.

Das ist für sich genommen nicht der Grund, warum Codex Security nicht auf einem SAST-Bericht basiert.

Das tiefergehende Problem ist, was passiert, nachdem du erfolgreich eine Quelle zu einem Problem zurückverfolgt hast.

Selbst wenn die statische Analyse Eingaben über mehrere Funktionen und Ebenen hinweg korrekt nachverfolgt, muss sie dennoch die Frage beantworten, die tatsächlich darüber entscheidet, ob eine Sicherheitslücke vorliegt:

Nehmen wir ein gängiges Muster: Code ruft vor dem Rendern nicht vertrauenswürdiger Inhalte beispielsweise sanitize_html() auf. Eine statische Analyse kann feststellen, dass die Bereinigung ausgeführt wurde. Was es in der Regel nicht feststellen kann, ist, ob diese Bereinigung tatsächlich für den gegebenen Rendering-Kontext, die Template-Engine, das Kodierungsverhalten und die jeweiligen nachgelagerten Transformationen ausreicht.

Da wird es knifflig. Das Problem ist nicht nur, ob Daten eine Sicherheitslücke erreichen. Es geht darum, ob die Prüfungen im Code den Wert tatsächlich so einschränken, wie vom System angenommen.

Anders gesagt: Es gibt einen großen Unterschied zwischen „der Code ruft den Sanitizer auf“ und „das System ist sicher.“

Hier ist ein Muster, das in realen Systemen ständig auftaucht.

Eine Webanwendung empfängt einen JSON-Payload, extrahiert eine redirect_url, validiert sie anhand einer Allowlist-Regex, URL-decodiert sie und übergibt das Ergebnis an einen Redirect-Handler.

Ein klassischer Source-to-Sink-Bericht kann den Fluss beschreiben:

nicht vertrauenswürdige Eingabe → Regex-Prüfung → URL-Dekodierung → Weiterleitung

Aber die eigentliche Frage ist nicht, ob die Prüfung existiert. Entscheidend ist, ob diese Prüfung den Wert nach den folgenden Transformationen noch einschränkt.

Wenn der Regex vor der Dekodierung ausgeführt wird, schränkt er dann tatsächlich die dekodierte URL so ein, wie der Redirect-Handler sie interpretiert?

Das zu beantworten bedeutet, über die gesamte Transformationskette nachzudenken: was der Regex zulässt, wie sich Decodierung und Normalisierung verhalten, wie das URL-Parsing mit Randfällen umgeht und wie die Redirect-Logik Schemas und Authorities auflöst.

Viele der Schwachstellen, die in der Praxis relevant sind, sehen so aus: Fehler bei der Reihenfolge der Operationen, partielle Normalisierung, Mehrdeutigkeiten beim Parsen und Diskrepanzen zwischen Validierung und Interpretation. Der Datenfluss ist sichtbar. Die Schwäche liegt darin, wie Einschränkungen durch die Transformationskette übertragen werden – oder nicht übertragen werden.

Das ist nicht nur ein theoretisches Muster. In CVE-2024-29041⁠(wird in einem neuen Fenster geöffnet) war Express von einem Open-Redirect-Problem betroffen, bei dem fehlerhaft formatierte URLs gängige Allowlist-Implementierungen umgehen konnten, aufgrund der Art und Weise, wie Weiterleitungsziele kodiert und anschließend interpretiert wurden. Der Datenfluss war unkompliziert. Die schwierigere Frage – und diejenige, die darüber entschied, ob der Bug existierte – war, ob die Validierung nach der Transformationskette noch gültig war.

Codex Security basiert auf einem einfachen Ziel: den Triage-Aufwand zu reduzieren, indem Probleme mit aussagekräftigeren Belegen aufgedeckt werden. Im Produkt bedeutet das, repo-spezifischen Kontext (einschließlich eines Bedrohungsmodells) zu verwenden und hochsignalige Probleme in einer isolierten Umgebung zu validieren, bevor sie aufgedeckt werden. 

Wenn Codex Security auf eine Grenze stößt, die nach „Validierung“ oder „Bereinigung“ aussieht, wird dies nicht als erledigt behandelt. Es versucht zu verstehen, was der Code zu garantieren versucht – und dann versucht es, diese Garantie zu widerlegen.

In der Praxis sieht das in der Regel wie eine Kombination folgender Schritte aus:

• Den relevanten Codepfad mit vollständigem Repository-Kontext lesen, wie es Sicherheitsforscher tun würden, und nach Diskrepanzen zwischen Absicht und Implementierung suchen. Dies umfasst Kommentare, aber das Modell glaubt Kommentaren nicht unbedingt. Daher ist es für es nicht verwirrend, wenn du //Halvar sagt: das ist kein Bug über deinen Code setzt, falls es tatsächlich einen Bug gibt.
• Das Problem auf die kleinste testbare Einheit reduzieren (zum Beispiel die Transformationspipeline um eine einzelne Eingabe herum), sodass du darüber nachdenken kannst, ohne dass der Rest des Systems im Weg ist. In diesem Sinne extrahiert Codex Security winzige Code-Schnipsel und schreibt dann Mikro-Fuzzer dafür.
• Reasoning über Einschränkungen über mehrere Transformationen hinweg, statt jede Prüfung unabhängig zu behandeln. Wo angemessen, kann dies eine Formalisierung als Erfüllbarkeitsfrage umfassen. Mit anderen Worten geben wir dem Modell Zugriff auf eine Python-Umgebung mit z3-solver, und es ist gut darin, sie bei Bedarf zu nutzen, so wie es auch ein Mensch tun müsste, wenn er oder sie ein besonders kompliziertes Eingabe-Constraint-Problem beantworten soll. Dies ist besonders nützlich, um Integer-Overflows oder ähnliche Fehler bei nicht standardisierten Architekturen zu untersuchen.
• Wo möglich, Hypothesen in einer Sandbox-Validierungsumgebung auf den Prüfstand stellen, um „das könnte ein Problem sein“ von „das ist ein Problem“ zu unterscheiden. Es gibt keinen besseren Beweis als einen vollständigen End-to-End-PoC mit dem im Debug-Modus kompilierten Code. 

Das ist der entscheidende Wandel: Statt bei „eine Prüfung existiert“ stehen zu bleiben, drängt das System auf „die Invariante gilt (oder nicht), und hier sind die Belege“. Und das Modell wählt das beste Tool für den Job aus.

Eine logische Reaktion ist: warum nicht beides? Mit einem SAST-Bericht beginnen und dann den Agenten nutzen, um tiefergehende Schlussfolgerungen zu finden.

Es gibt Fälle, in denen vorab berechnete Erkenntnisse hilfreich sind – insbesondere bei engen, bekannten Bugklassen. Aber bei einem Agenten, der darauf ausgelegt ist, Schwachstellen im Kontext zu entdecken und zu validieren, führt der Einstieg über einen SAST-Bericht zu drei vorhersehbaren Fehlermodi.

Zunächst kann er eine vorzeitige Eingrenzung fördern. Eine Befundliste ist eine Übersicht, wo ein Tool bereits gesucht hat. Wenn du diese als Ausgangspunkt behandelst, kannst du das System dazu bringen, unverhältnismäßig viel Aufwand in denselben Bereichen zu betreiben, dieselben Abstraktionen zu verwenden und ganze Klassen von Problemen zu übersehen, die nicht in das Weltbild des Tools passen.

Zweitens können damit implizite Wertungen eingeführt werden, die sich nur schwer rückgängig machen lassen. Viele SAST-Befunde kodieren Annahmen über Bereinigung, Validierung oder Vertrauensgrenzen. Wenn diese Annahmen falsch sind – oder einfach unvollständig – kann ihre Einspeisung in die Schlussfolgerungsschleife die Arbeit des Agenten von „untersuchen“ zu „bestätigen oder verwerfen“ verschieben, was nicht dem entspricht, was wir von dem Agenten erwarten.

Drittens wird damit die Bewertung des Reasoning-Systems erschwert. Wenn die Pipeline mit SAST-Ausgaben beginnt, wird es schwierig zu unterscheiden, was der Agent durch seine eigene Analyse entdeckt hat und was er von einem anderen Tool übernommen hat. Diese Trennung ist wichtig, wenn du die Fähigkeiten des Systems genau messen möchtest, und dies ist notwendig, damit sich das System im Laufe der Zeit verbessern kann.

Deshalb haben wir Codex Security entwickelt, um dort anzusetzen, wo Sicherheitsforschung beginnt: beim Code und der Absicht des Systems, wobei Validierung genutzt wird, um die Messlatte für Zuverlässigkeit anzuheben, bevor wir einen Menschen unterbrechen.

SAST-Tools können hervorragend für die Aufgaben sein, für die sie entwickelt wurden: sichere Codierstandards durchzusetzen, einfache Source-to-Sink-Probleme zu erkennen und bekannte Muster im großen Stil mit vorhersehbaren Kompromissen zu erkennen. Sie können ein starker Bestandteil einer tiefgehenden Verteidigung sein.

Dieser Beitrag ist enger gefasst: Es geht darum, warum ein Agent, der dafür entwickelt wurde, Schlussfolgerungen aus Verhalten zu ziehen und Erkenntnisse zu validieren, seine Arbeit nicht auf eine statische Erkenntnisliste stützen sollte.

Es sollte hier auch eine damit zusammenhängende Beschränkung des reinen Source-to-Sink-Denkens hervorgehoben werden: Nicht jede Schwachstelle ist ein Datenflussproblem. Viele reale Fehler sind Probleme mit Zuständen und Invarianten – Umgehungen von Workflows, Lücken in der Autorisierung und „das System ist im falschen Zustand“-Bugs. Bei diesen Arten von Fehlern erreicht ein verunreinigter Wert kein einzelnes „dangerous sink.“ Das Risiko liegt darin, was das Programm als immer zutreffend annimmt. 

Wir erwarten, dass sich das Ökosystem der Sicherheitstools weiterentwickelt: statische Analyse, Fuzzing, Laufzeitschutzmechanismen und agentische Workflows werden alle eine Rolle spielen.

Worin Codex Security wirklich gut sein soll, ist der Teil, der Sicherheitsteams am meisten kostet: aus „das sieht verdächtig aus“ „das ist echt, so schlägt es fehl, und hier ist ein Fix, der zur Systemabsicht passt“ zu machen. 

Wenn du mehr darüber erfahren möchtest, wie Codex Security Repositorys scannt, Ergebnisse validiert und Korrekturen vorschlägt, sieh dir unsere Dokumentation⁠(wird in einem neuen Fenster geöffnet) an.