Codex Security startet als Security Agent im Preview

Codex Security ist ein KI-gestützter Application-Security-Agent, der ein Softwareprojekt kontextbasiert analysiert, Schwachstellen priorisiert, möglichst validiert und konkrete Fixes vorschlägt. In der Research Preview wird der Zugang über Codex Web für ChatGPT Enterprise, Business und Edu ausgerollt, im ersten Monat mit kostenloser Nutzung. Der Kernnutzen: weniger Fehlalarme, weniger Triage-Arbeit und schnelleres Shipping von sicherem Code, trotz steigender Entwicklungsgeschwindigkeit durch Agenten.

Übersicht:

Warum Kontext zählt statt endloser Findings

Codex Security zielt darauf, nicht möglichst viel zu melden, sondern möglichst belastbare Sicherheitsprobleme zu finden, inklusive umsetzbarer Patches. Das reduziert die typische Flut an Low-Impact-Treffern und False Positives, die Security-Teams sonst in Triage-Schleifen bindet. Gleichzeitig soll der Review nicht zum Engpass werden, wenn Entwicklung durch Automatisierung schneller wird.

Viele KI-Scanner bewerten Code isoliert und wissen wenig über Rollenmodelle, Trust Boundaries oder reale Deployment-Pfade. Ohne Systemwissen wirkt vieles kritisch, ist aber praktisch kaum ausnutzbar, oder umgekehrt, echte Risiken werden unterschätzt, weil der Kontext fehlt. Codex Security setzt deshalb zuerst auf Projektverständnis, bevor es Schweregrade und Fix-Vorschläge ableitet.

Entscheidungsregel für den Einsatz

Ein Team profitiert besonders dann, wenn die Triage mehr Zeit kostet als die eigentliche Behebung oder wenn Merge-Raten so hoch sind, dass man nicht mehr jedes sicherheitsrelevante Delta manuell prüfen kann. Als Faustregel gilt: Wenn Security-Reviews regelmäßig Releases verzögern oder Findings zu oft nachträglich als „nicht relevant“ geschlossen werden, lohnt ein kontextbasierter Agent. Wer zusätzlich eine testnahe Umgebung bereitstellen kann, bekommt die größte Reduktion von Fehlalarmen, weil Validierung am laufenden System möglich wird.

Mini-Modell zur Markteinordnung

Bei AppSec-Agenten entscheiden meist drei Achsen über den praktischen Nutzen:

• Kontext-Tiefe: Kennt das Tool Architektur, Trust-Zonen und typische Datenflüsse des Projekts?
• Validierungsgrad: Werden Findings in einer Sandbox oder gegen eine projektnahe Umgebung überprüft, statt nur Muster zu matchen?
• Fix-Nähe: Liefert das System Patches, die zur Codebasis passen und Regressionen vermeiden helfen?

So arbeitet Codex Security vom Scan bis zum Patch

Codex Security kombiniert nach Angaben des Unternehmens ein Agenten-Setup mit frontier Modellen und automatisierter Prüfung. Der Ablauf ist darauf ausgelegt, den Sicherheitskontext explizit zu machen, Findings zu belegen und Änderungen so vorzuschlagen, dass sie in Review und Betrieb stabil bleiben. Der Dienst war zuvor unter dem Namen Aardvark bekannt und wurde in einer privaten Beta weiterentwickelt.

1) Systemkontext aufbauen und Threat Model editierbar machen

Nach der Konfiguration analysiert der Agent das Repository mit Blick auf sicherheitsrelevante Struktur, etwa Authentifizierungspfade, Schnittstellen, Abhängigkeiten und Grenzen zwischen Komponenten. Daraus entsteht ein projektspezifisches Threat Model, das beschreibt, was das System tut, welchen Komponenten es vertraut und wo Angriffsflächen plausibel sind. Dieses Modell bleibt editierbar, damit Teams Annahmen korrigieren und den Agenten auf die reale Architektur ausrichten können.

2) Findings priorisieren und, wo möglich, verifizieren

Mit dem Threat Model als Leitplanke sucht Codex Security nach Schwachstellen und bewertet sie anhand der erwartbaren Auswirkung im konkreten System. Wo eine sichere Testumgebung verfügbar ist, werden Funde in isolierten Validierungsumgebungen „gegengeprüft“, um Signal von Rauschen zu trennen. Ist eine projektspezifische Umgebung angebunden, kann die Prüfung näher am laufenden System stattfinden, inklusive belastbarer Proof-of-Concepts, was Security-Entscheidungen beschleunigt.

Begriffe kurz eingeordnet: SSRF bedeutet, dass ein Server unerwünschte Requests in interne Netze ausführt, oft über scheinbar harmlose URL-Parameter, Details bei OWASP. Solche Themen sind stark kontextabhängig, weil interne Dienste, Netzwerkregeln und erlaubte Egress-Ziele über die reale Ausnutzbarkeit entscheiden.

3) Fixes vorschlagen, die zur Systemabsicht passen

Im letzten Schritt werden Patches vorgeschlagen, die sich an umgebendem Verhalten und beabsichtigter Logik orientieren. Ziel ist, Sicherheitsgewinne zu erzielen, ohne Nebenwirkungen zu provozieren, damit Reviews schneller durchgehen und Änderungen seltener zurückgerollt werden. Findings lassen sich filtern, damit Teams auf die für sie wichtigsten Risikoklassen fokussieren.

Feedback ist Teil des Loops: Wenn Teams die Kritikalität eines Findings nach unten oder oben korrigieren, soll das Modell diese Signale nutzen, um Threat Model und Präzision in späteren Läufen zu schärfen.

Praxisbeispiel aus einem typischen SaaS-Setup

Angenommen, eine Multi-Tenant-Anwendung hat einen Endpoint, der Webhooks verarbeitet und dazu externe URLs abruft. Ein klassischer Scanner meldet „mögliche SSRF“ in mehreren Codepfaden, ohne zu wissen, ob Egress eingeschränkt ist oder ob interne Metadaten-Endpunkte erreichbar sind. Ein kontextbasierter Ansatz kann im Threat Model festhalten, welche Netze als intern gelten, welche Services besonders sensibel sind und welche Requests erlaubt sind, und kann anschließend Findings priorisieren, die tatsächlich tenant-übergreifende Auswirkungen haben, inklusive eines Fix-Vorschlags, etwa URL-Allowlisting plus harte DNS- und IP-Checks.

Zahlen aus der Beta und was sie aussagen

In frühen internen Einsätzen fand Codex Security laut Unternehmensangaben unter anderem eine reale SSRF sowie eine kritische Authentifizierungs-Schwachstelle, die mehrere Tenants betraf, und weitere Probleme, die das Security-Team innerhalb weniger Stunden behob. Ein Schwerpunkt der Beta war nicht „mehr Treffer“, sondern bessere Präzision und realistischere Schweregrade.

• Weniger Rauschen: Bei wiederholten Scans derselben Repositories stieg die Präzision, in einem dokumentierten Fall sank das Rauschen seit dem initialen Rollout um 84%.
• Realistischere Severity: Die Rate an überhöht eingestuften Findings ging um mehr als 90% zurück.
• Weniger False Positives: Die False-Positive-Rate sank über alle Repositories hinweg um mehr als 50%.

Zur Skalierung nennt das Unternehmen Messwerte der letzten 30 Tage aus der Beta-Kohorte: mehr als 1,2 Millionen gescannte Commits in externen Repositories, dabei 792 kritische und 10.561 Findings mit hoher Schwere. Kritische Probleme traten in weniger als 0,1% der gescannten Commits auf, was als Hinweis gewertet wird, dass sich auch bei großen Code-Mengen gezielt nach hochrelevanten Issues suchen lässt, ohne Review-Teams mit Masse zu überfahren.

Ein externer Tester, NETGEAR, beschreibt den Nutzen sinngemäß so: Die Einbindung in bestehende Security-Workflows sei unkompliziert gewesen, die Ergebnisse wirkten klar und vollständig, ähnlich wie zusätzliche Unterstützung durch erfahrene Product-Security-Researcher.

Unterstützung für Open Source und konkrete CVE-Beispiele

Open-Source-Komponenten tragen einen großen Teil der modernen Softwarelandschaft, auch in kommerziellen Systemen. In Gesprächen mit Maintainerinnen und Maintainern zeigte sich laut Unternehmen ein wiederkehrendes Problem: Es fehlt nicht an Reports, es fehlt an verwertbaren Reports, weil zu viele Meldungen unpräzise sind und zusätzliche Triage erzeugen. Codex Security soll deshalb bevorzugt Findings liefern, die schnell überprüfbar und direkt fixbar sind.

Das Unternehmen berichtet, dass es kritische Schwachstellen an mehrere stark verbreitete Projekte gemeldet hat, darunter OpenSSH, GnuTLS, Gogs, libssh, PHP und Chromium. Insgesamt wurden 14 CVEs vergeben, bei zwei Fällen gab es eine doppelte Meldung.

Codex for OSS Programm

Parallel läuft der Aufbau eines Programms für Maintainer: „Codex for OSS“ soll unter anderem kostenlose ChatGPT Pro und Plus Accounts, Code-Review-Unterstützung und Zugang zu Codex Security bündeln. Projekte wie vLLM hätten Codex Security bereits genutzt, um Schwachstellen zu finden und im normalen Maintainer-Workflow zu patchen, eine Ausweitung des Programms ist angekündigt.

Anhang mit OSS-Funden aus der Übersicht

• GnuTLS: Off-by-one Heap-Buffer-Overflow in certtool, CVE-2025-32990
• GnuTLS: Heap-Buffer-Overread bei SCT-Extension-Parsing, CVE-2025-32989
• GnuTLS: Double-Free beim Export von otherName SAN, CVE-2025-32988
• GOGS: 2FA-Bypass, CVE-2025-64175
• GOGS: Unautorisierter Bypass, CVE-2026-25242
• download_ephemeral und download_children: Path Traversal mit beliebigem Write, CVE-2025-35430
• LdapUserMap: LDAP-Injection über Filter und DN, CVE-2025-35431
• resend_email_verification: Unautentifizierter DoS und Mail-Abuse, CVE-2025-35432 und CVE-2025-35436
• User::update_user: Session-Rotation fehlt bei Passwortänderung, CVE-2025-35433
• Elasticsearch Client: TLS-Verifikation deaktiviert, CVE-2025-35434
• /api/streams/depth: DoS durch Division by zero, CVE-2025-35435
• gpg-agent: Stack-Buffer-Overflow via PKDECRYPT mit ECC KEM, CVE-2026-24881
• TPM2: Stack-basierter Buffer-Overflow in PKDECRYPT für RSA und ECC wegen fehlender Ciphertext-Längenprüfung, CVE-2026-24882
• CMS/PKCS7: Stack-Buffer-Overflow bei AES-GCM ASN.1 Parametern, CVE-2025-15467
• PKCS#12: PBMAC1 PBKDF2 keyLength Overflow plus MAC-Bypass, CVE-2025-11187

So startet ein Team mit Codex Security

Der Rollout erfolgt über die nächsten Tage für ChatGPT Enterprise, Business und Edu. Die Nutzung ist im ersten Monat kostenfrei, bereitgestellt über Codex Web.

1. Repository anbinden: Scan konfigurieren und sicherstellen, dass der Agent genügend Kontext bekommt, etwa über Architekturhinweise oder Security-Annahmen.
2. Threat Model prüfen: Das generierte Modell editieren, bis Trust Boundaries, kritische Daten und Auth-Flows stimmen.
3. Validierung ermöglichen: Wenn machbar, eine sandboxed oder testnahe Umgebung bereitstellen, um Findings belastbarer zu machen.
4. Fix-Review standardisieren: Patch-Vorschläge wie normale PRs behandeln, mit Tests, Code-Ownern und klaren Merge-Kriterien.
5. Feedback diszipliniert geben: Kritikalität nur mit Begründung anpassen, damit das System beim nächsten Lauf präziser wird.

Für Setup-Hinweise und aktuelle Produktdetails bietet sich die Dokumentation des Anbieters an, etwa über help.openai.com sowie die Entwicklerdokumentation unter platform.openai.com/docs.