OpenAI veroeffentlicht Codex Security als agentenbasierten Security-Scanner
OpenAI hat Codex Security als Open-Source-TypeScript-SDK veroeffentlicht. Der agentengetriebene Scanner orchestriert parallele Discovery-Worker, prueft Findings per LLM-Reasoning, erstellt Patches und verifiziert Fixes autonom, inklusive CI-Integration.
Veröffentlicht am 9. Oktober • Zuerst veröffentlicht auf mech.app
OpenAI hat soeben Codex Security als Open-Source-TypeScript-SDK mit über 11.000 Sternen veröffentlicht. Es ist kein weiteres statisches Analysewerkzeug. Es ist ein agentengesteuerter Sicherheitsscanner, der parallele Discovery-Worker orchestriert, Funde mit LLM-Reasoning validiert, Patches generiert und Korrekturen autonom überprüft. Das ist das Ergebnis, wenn Security-Tooling agentisch statt regelbasiert wird.
Klassische SAST-Werkzeuge führen Mustervergleiche aus und werfen Alarmmeldungen aus. Codex Security durchläuft eine mehrstufige Pipeline: Discovery-Agents scannen den Code, Validation-Agents filtern Fehlalarme heraus, Patch-Agents generieren Korrekturen, und Verification-Agents bestätigen, dass die Patches funktionieren. Jede Stufe verfügt über ein eigenes State-Management, eigene Tool-Grenzen und eigene Fehlermodi. So funktioniert die zugrunde liegende Technik.
Codex Security unterteilt die Discovery in Worker-Pools. Wenn man cs scan. in einem Repository ausführt, startet die CLI mehrere Discovery-Worker, die parallel auf verschiedenen Codepfaden arbeiten. Jeder Worker ist ein Node.js-Prozess, der im Hintergrund Python-Analysewerkzeuge ausführt.
Die CLI benötigt Node.js 22.13.0+ (innerhalb von 22.x) oder 24.x/26.x sowie Python 3.10+. Für Python 3.10 wird zusätzlich tomli für das TOML-Parsing benötigt. Diese Dual-Runtime-Anforderung besteht, weil die Discovery-Ebene Python-basierte Sicherheitstools verwendet (wahrscheinlich Semgrep, Bandit oder Ähnliches), während die Orchestrierung und die LLM-Integration in TypeScript laufen.
// Vereinfachtes Muster für die Worker-Koordination interface ScanWorker { id: string; targetPaths: string []; findings: CandidateFinding []; } async function runDeepScan ( repoPath: string ): Promise < Finding [] > { const workers = allocateWorkers ( repoPath ); const results = await Promise. all ( workers. map ( w => runWorker ( w. targetPaths )) ); const merged = deduplicateFindings ( results. flat ()); return validateFindings ( merged ); } Vollbildmodus aktivieren Vollbildmodus beenden Validierungspipeline und Tool-Grenzen Die Discovery erzeugt Kandidaten-Funde. Die Validierung entscheidet, welche Kandidaten echte Schwachstellen sind. Hier kommt die Agent-Ebene ins Spiel.
Tool-Grenzen spielen dabei eine wichtige Rolle. Der Validation-Agent hat keinen Schreibzugriff auf das Repository. Er kann Code und Policy-Dateien lesen, aber er kann weder Quellcode verändern noch Patches committen. Diese Trennung verhindert, dass ein Validierungsfehler die Codebasis beschädigt.
Die CLI unterstützt eigene Severity-Rubriken. Man kann eine eigene Risikobewertungslogik definieren und an die Validierungsstufe übergeben. Auf diese Weise können Teams die Entscheidungen der Agents an interne Sicherheitsstandards anpassen, statt auf generische CVE-Bewertungen angewiesen zu sein.
Sobald ein Fund validiert wurde, generiert der Patch-Agent eine Korrektur. Dies ist ein separater Agent mit anderem Tool-Zugriff:
Die Verifikation ist entscheidend. Der Agent kann Unit-Tests, Linter oder Type-Checker ausführen, um den Patch zu validieren. Schlägt die Verifikation fehl, kann der Agent es mit einem angepassten Patch erneut versuchen oder den Fund als manuell zu bearbeitenden Fall kennzeichnen.
Codex Security lässt sich durch den Betrieb im Headless-Modus in CI-Pipelines integrieren. Man setzt OPENAI_API_KEY oder CODEX_API_KEY in der Umgebung und führt cs scan. im Build-Container aus.
Auf entfernten oder Headless-Maschinen verwendet man cs login --device-auth, sofern der Workspace dies erlaubt, oder meldet sich per SSH mit Port-Forwarding an. Die CLI unterstützt SSH-Agent-Forwarding, um sich zu authentifizieren, ohne Anmeldeinformationen auf dem CI-Runner zu speichern.
Observability-Hooks ermöglichen es Teams, Agent-Entscheidungen zu prüfen:
Das ist hilfreich, wenn man nachvollziehen möchte, warum ein Fund validiert oder abgelehnt wurde. Man kann den Validierungsschritt mit anderem Kontext oder anderen Rubriken erneut durchspielen.
Codex Security speichert den gesamten Scan-Zustand lokal unter ~/.codex-security/scans/. Jede Scan-Sitzung enthält:
Dieses Local-First-Design bedeutet, dass man frühere Scans durchsehen, Funde über Versionen hinweg vergleichen und die Validierung erneut ausführen kann, ohne neu scannen zu müssen. Die CLI bietet cs browse an, um gespeicherte Sitzungen zu durchsuchen.
State-Isolation ist wichtig. Jede Scan-Sitzung ist unabhängig. Wenn man mehrere Scans gleichzeitig ausführt (zum Beispiel auf unterschiedlichen Branches), beeinträchtigen sie sich nicht gegenseitig. Die Session-ID wird aus der Startzeit des Scans und dem Repository-Pfad abgeleitet.
Die Agent-Architektur erzwingt strenge Grenzen:
Discovery- und Verification-Agents rufen keine externen APIs auf. Nur Validation- und Patch-Generierungs-Agents kommunizieren mit OpenAI. Dies begrenzt die Angriffsfläche, falls ein Agent kompromittiert wird.
Die CLI unterstützt außerdem den Daybreak-Blue-Zugang für Kunden mit Zugriff auf das erweiterte Cybersecurity-Programm von OpenAI. Mit --cyber-access-program daybreak_blue wird dieser aktiviert. Andernfalls lässt man das Flag weg oder verwendet --cyber-access-program standard.
Codex Security unterstützt drei Deployment-Varianten:
Für CI erkennt die CLI, wenn sie in einer nicht-interaktiven Umgebung läuft, und überspringt Eingabeaufforderungen. Bei Funden mit hoher Schwere wird die Ausführung mit einem von null verschiedenen Exit-Code beendet, wodurch der Build fehlschlägt.
Das TypeScript-SDK ist außerdem als @openai/codex-security auf npm verfügbar. Man kann die Scan-Logik in eigene Werkzeuge oder Dashboards einbetten. Das SDK stellt dieselben Orchestrierungs-Primitives bereit: runScan(), validateFindings(), generatePatch(), verifyPatch().
Agentengesteuertes Security-Scanning bringt neue Fehlermodi mit sich, die statische Werkzeuge nicht kennen:
Die CLI enthält eine Duplikaterkennung, um zu vermeiden, dass derselbe Fund über mehrere Scans hinweg erneut validiert wird. Das senkt die API-Kosten und beschleunigt inkrementelle Scans.
Codex Security eignet sich, wenn man agentengesteuerte Validierung und Patching auf klassisches Security-Scanning aufsetzen möchte. Es passt gut zu Teams, die:
Die Orchestrierung ist solide. Parallele Worker, isolierter Zustand und strenge Tool-Grenzen machen es produktionsreif. Der wichtigste Kompromiss ist die LLM-Abhängigkeit: Man tauscht Determinismus gegen intelligentere Validierung und automatisiertes Patching.
Mit Vorlagen lassen sich häufige Fragen schnell beantworten oder Codeausschnitte zur Wiederverwendung speichern.
Möchten Sie diesen Kommentar wirklich ausblenden? Er wird in Ihrem Beitrag verborgen, bleibt jedoch über den Permalink des Kommentars sichtbar.
Für weitere Maßnahmen können Sie diese Person blockieren und/oder einen Missbrauchsfall melden.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 9 • Originally published at mech.app
OpenAI just released Codex Security as an open-source TypeScript SDK with 11K+ stars. It's not another static analysis tool. It's an agent-driven security scanner that orchestrates parallel discovery workers, validates findings with LLM reasoning, generates patches, and verifies fixes autonomously. This is what happens when security tooling becomes agentic rather than rule-based.
Traditional SAST tools run pattern matchers and dump alerts. Codex Security runs a multi-stage pipeline: discovery agents scan code, validation agents filter false positives, patch agents generate fixes, and verification agents confirm the patches work. Each stage has its own state management, tool boundaries, and failure modes. Here's how the plumbing works.
Codex Security splits discovery into worker pools. When you run cs scan. on a repository, the CLI spawns multiple discovery workers that operate concurrently across different code paths. Each worker is a Node.js process running Python analysis tools underneath.
The CLI requires Node.js 22.13.0+ (within 22.x) or 24.x/26.x, plus Python 3.10+. Python 3.10 also needs tomli for TOML parsing. This dual-runtime requirement exists because the discovery layer uses Python-based security tools (likely Semgrep, Bandit, or similar) while the orchestration and LLM integration run in TypeScript.
// Simplified worker coordination pattern interface ScanWorker { id: string; targetPaths: string []; findings: CandidateFinding []; } async function runDeepScan ( repoPath: string ): Promise < Finding [] > { const workers = allocateWorkers ( repoPath ); const results = await Promise. all ( workers. map ( w => runWorker ( w. targetPaths )) ); const merged = deduplicateFindings ( results. flat ()); return validateFindings ( merged ); } Enter fullscreen mode Exit fullscreen mode Validation Pipeline and Tool Boundaries Discovery produces candidate findings. Validation decides which candidates are real vulnerabilities. This is where the agent layer kicks in.
Tool boundaries matter here. The validation agent does not have write access to the repository. It can read code and policy files, but it cannot modify source or commit patches. This separation prevents a validation bug from corrupting the codebase.
The CLI supports custom severity rubrics. You can define your own risk scoring logic and pass it to the validation stage. This lets teams align agent decisions with internal security standards instead of relying on generic CVE scores.
Once a finding is validated, the patch agent generates a fix. This is a separate agent with different tool access:
Verification is critical. The agent can run unit tests, linters, or type checkers to validate the patch. If verification fails, the agent can retry with a modified patch or flag the finding as requiring manual intervention.
Codex Security integrates into CI pipelines by running in headless mode. Set OPENAI_API_KEY or CODEX_API_KEY in the environment, then run cs scan. in your build container.
For remote or headless machines, use cs login --device-auth if your workspace allows it, or sign in over SSH with port forwarding. The CLI supports SSH agent forwarding to authenticate without storing credentials on the CI runner.
Observability hooks let teams audit agent decisions:
This is useful when debugging why a finding was validated or rejected. You can replay the validation step with different context or rubrics.
Codex Security stores all scan state locally in ~/.codex-security/scans/. Each scan session includes:
This local-first design means you can browse past scans, compare findings across versions, and re-run validation without re-scanning. The CLI provides cs browse to navigate saved sessions.
State isolation is important. Each scan session is independent. If you run multiple scans concurrently (e.g., on different branches), they don't interfere with each other. The session ID is derived from the scan start time and repository path.
The agent architecture enforces strict boundaries:
Discovery and verification agents do not call external APIs. Only validation and patch generation agents communicate with OpenAI. This limits the attack surface if an agent is compromised.
The CLI also supports Daybreak Blue access for customers with access to OpenAI's advanced cybersecurity program. Use --cyber-access-program daybreak_blue to enable it. Otherwise, omit the flag or use --cyber-access-program standard.
Codex Security supports three deployment shapes:
For CI, the CLI detects when it's running in a non-interactive environment and skips prompts. It exits with a non-zero code if high-severity findings are detected, which fails the build.
The TypeScript SDK is also available as @openai/codex-security on npm. You can embed the scanning logic into custom tooling or dashboards. The SDK exposes the same orchestration primitives: runScan(), validateFindings(), generatePatch(), verifyPatch().
Agent-driven security scanning introduces new failure modes that static tools don't have:
The CLI includes duplicate detection to avoid re-validating the same finding across scans. This reduces API costs and speeds up incremental scans.
Use Codex Security when you need agent-driven validation and patching on top of traditional security scanning. It's a good fit for teams that:
The orchestration plumbing is solid. Parallel workers, isolated state, and strict tool boundaries make it production-ready. The main trade-off is LLM dependency: you're exchanging determinism for smarter validation and automated patching.