OpenAI hat offengelegt, warum Codex bewusst auf klassisches Static Application Security Testing verzichtet – und damit eine grundsätzliche Debatte darüber angestoßen, wie KI-gestützte Entwicklungswerkzeuge in moderne Sicherheitsarchitekturen eingebettet werden sollten.
OpenAI Codex verzichtet bewusst auf SAST – und erklärt warum
OpenAI hat in einem aktuellen Beitrag offengelegt, weshalb das Sicherheitskonzept von Codex keine klassische Static Application Security Testing-Komponente enthält. Die Entscheidung ist nicht Nachlässigkeit, sondern Kalkül – und sie wirft grundsätzliche Fragen darüber auf, wie KI-gestützte Entwicklungswerkzeuge künftig in Sicherheitsarchitekturen eingebettet werden sollten.
Statische Analyse: Warum Codex einen anderen Weg geht
SAST-Tools durchleuchten Quellcode systematisch auf bekannte Schwachstellenmuster – Buffer Overflows, SQL-Injection-Risiken, unsichere Bibliotheksaufrufe. Das Verfahren ist etabliert, regelbasiert und reproduzierbar. Genau das ist aber auch seine Grenze.
Codex arbeitet anders. Das Modell versteht Kontext. Es erkennt nicht nur, dass eine Funktion potenziell unsicher aussieht, sondern kann – zumindest in Teilen – einschätzen, in welchem semantischen Zusammenhang sie steht. OpenAI argumentiert, dass das starre Regelwerk eines SAST-Scanners diesem kontextuellen Verständnis nicht gerecht wird und in vielen Fällen zu False Positives führt, die Entwicklerteams mehr belasten als schützen.
Mehr Rauschen, weniger Signal.
Das Sicherheitsmodell hinter Codex
Statt SAST setzt OpenAI auf ein mehrschichtiges Sicherheitsmodell, das tief im Trainings- und Inferenzprozess verankert ist. Codex wurde darauf ausgerichtet, von sich aus keine gefährlichen Codevorschläge zu generieren – Sicherheitsbewusstsein also nicht als nachgelagerten Filter, sondern als inhärente Eigenschaft des Modells selbst.
Das klingt ambitioniert. Und es ist auch nicht ohne Risiko. Denn ein solches Modell ist schwerer zu prüfen als ein regelbasierter Scanner. Wer kontrolliert, ob das Modell tatsächlich konsistent sicher agiert? Welche Auditprozesse greifen, wenn ein Ausgabe-Snippet doch problematisch ist?
OpenAI räumt ein, dass das Konzept keine vollständige Sicherheitsgarantie bietet – und empfiehlt ausdrücklich, Codex nicht als einzige Sicherheitsinstanz im Entwicklungsprozess zu betrachten.
Was das für DevSecOps-Teams konkret bedeutet
Für Sicherheitsverantwortliche in Unternehmen ist die Botschaft eindeutig: Codex ergänzt, ersetzt aber nicht. Wer KI-Coding-Assistenten in CI/CD-Pipelines integriert, sollte die bestehende Sicherheitsinfrastruktur – SAST, DAST, Software Composition Analysis – nicht zurückbauen.
Im Gegenteil: Die sinnvolle Kombination wird zum eigentlichen Kompetenzfeld. Codex kann dabei helfen, Schwachstellen frühzeitig im Entwicklungsprozess zu adressieren, noch bevor der Code in den Scanner läuft – ein Shift-Left-Ansatz, der in der Theorie viel Potenzial hat. Ob er in der Praxis hält, was er verspricht, hängt stark davon ab, wie Teams ihre Workflows anpassen und welche Validierungsprozesse sie um das Modell herum aufbauen.
Vertrauen ist gut. Verifizierung ist besser.
Einordnung für deutsche Unternehmen
Gerade in regulierten Branchen – Finanzdienstleistungen, Gesundheitswesen, kritische Infrastruktur – dürfte die Frage, ob KI-generierter Code hinreichend sicher ist, schnell auf dem Tisch der Compliance-Abteilung landen. Das BSI hat bislang keine spezifischen Vorgaben für den Einsatz von KI-Coding-Assistenten formuliert, aber bestehende Regelwerke wie die BSI-Grundschutz-Methodik oder NIS2-Anforderungen lassen wenig Interpretationsspielraum: Sicherheitsprüfungen bleiben Pflicht – unabhängig davon, wer oder was den Code geschrieben hat.
DevSecOps-Teams, die Codex oder ähnliche Werkzeuge einführen wollen, sollten das nicht als Vereinfachung ihrer Sicherheitsprozesse betrachten, sondern als eine weitere Variable, die in das bestehende Risikomanagement einzupreisen ist.
