OpenAI hat stillschweigend den Quellcode der Codex-Security-Befehlszeilenschnittstelle und des TypeScript-SDKs veröffentlicht. Das öffentlic...
OpenAI hat still und leise den Quellcode der Codex Security-Befehlszeilenschnittstelle und des TypeScript-SDKs veröffentlicht.
Dieses öffentliche Paket @openai/codex-security soll Sicherheits- und Engineering-Teams dabei helfen:
Die Codebasis wurde unter der Apache-Lizenz 2.0 veröffentlicht.
Das bedeutet, dass der CLI- und SDK-Code Open Source ist. Das bedeutet jedoch nicht, dass der gesamte Codex Security-Dienst, seine zugrunde liegenden Modelle, jeder geschützte Befund oder unbegrenzter Netzwerkzugriff jetzt kostenlos offline genutzt werden können.
Für die Ausführung von Scans ist weiterhin ein Codex Security-Zugriff erforderlich. OpenAI hat außerdem angegeben, dass bestimmte Scans gesamter Repositories, geschützte Befunde und erweiterte Cybersicherheitsanfragen möglicherweise eine Genehmigung über Trusted Access for Cyber erfordern.
Diese Unterscheidung ist wichtig:
Open-Source-CLI und SDK
≠
Open-Weight-Sicherheitsmodell
≠
Uneingeschränkter Cloud-Scan-Zugriff
Codex Security begann ursprünglich als internes Projekt namens Aardvark. Später fand es als Research-Preview-Anwendungssicherheitsagent den Weg in Codex, und das neue öffentliche Paket ermöglicht Entwicklern nun, den Scanner in lokale Terminals, interne Tools, Batch-Aktivitäten für Codebasen, Pre-Commit-Checks und CI-Pipelines zu bringen.
OpenAI stellte Aardvark erstmals im Oktober 2025 vor – einen intelligenten Sicherheitsforscher, der von GPT-5 angetrieben wird.
Das ursprüngliche System wurde entwickelt, um eher wie ein menschlicher Anwendungssicherheitsforscher zu arbeiten als wie ein traditioneller Signatur-Scanner.
Statt Code nur mit bekannten Mustern abzugleichen, konnte Aardvark:
Im März 2026 benannte OpenAI Aardvark in Codex Security um und integrierte es in Codex.
Das Produkt wurde über Codex Web als Research-Preview für ausgewählte ChatGPT-Tarifnutzer verfügbar gemacht und unterstützte verbundene GitHub-Repositories.
Die anschließende Open-Source-Veröffentlichung fügte eine weitere Bereitstellungsebene hinzu.
Entwickler können jetzt die CLI installieren oder das TypeScript-SDK importieren, während das verwaltete Codex Security-Cloud-Erlebnis weiterhin separat besteht.
Das öffentliche GitHub-Repository enthält:
Das Paket wird über npm veröffentlicht als:
@openai/codex-security
Die Apache-2.0-Lizenz der Codebasis erlaubt im Rahmen der Lizenzbedingungen typischerweise Nutzung, Modifikation und Weiterverbreitung.
Diese Veröffentlichung stellt keine Gewichte von GPT-5.6 Sol, Terra oder den dedizierten Codex Security-Modellen bereit.
Der Standardscan verwendet derzeit:
gpt-5.6-sol
Inferenzstärke: xhigh
Die CLI ruft den Inferenzdienst über authentifizierten Zugriff auf.
Das Repository dokumentiert außerdem Provider-Optionen (wie OpenRouter und Fireworks) für ausgewählte Modelle, aber Codex Security-Scan-Workflows und geschützte Netzwerkfähigkeiten können weiterhin eine Autorisierung von OpenAI erfordern.
Die Installation des npm-Pakets bedeutet nicht, dass Sie die Erlaubnis erhalten, jeden Scan auszuführen.
Die Dokumentation von OpenAI stellt klar:
Der öffentliche Code macht den Workflow überprüfbar und erweiterbar. Er entfernt nicht die Sicherheits- und Autorisierungsebenen rund um erweiterte Netzwerkzwecke.
KI-Programmieragenten erzeugen und modifizieren Software schneller, als viele Organisationen sie überprüfen können.
Das schafft einen Sicherheitsengpass.
Ein Produkt kann in Tagen oder Stunden von der Idee zur bereitgestellten Anwendung gelangen, während die traditionelle Anwendungssicherheitsprüfung möglicherweise weiterhin abhängt von:
Das Problem ist nicht nur, dass Entwickler keine Schwachstellenberichte haben.
Viele Maintainer erhalten bereits zu viele Berichte, darunter:
Codex Security ist um das gegenteilige Ziel herum entworfen: weniger, kontextreichere Befunde mit Beweisen, die Prüfern helfen zu entscheiden, was behoben werden sollte.
OpenAI beschreibt das System als mehrstufigen Anwendungssicherheits-Workflow.
Codex Security untersucht zunächst das Repository, um die sicherheitsrelevanten Strukturen im Projekt zu verstehen.
Es versucht zu identifizieren:
Das Ergebnis ist ein projektspezifisches Bedrohungsmodell – keine generische Checkliste.
Teams können Architekturdokumentation, Sicherheitsrichtlinien, Schwerpunktbereiche und bekannte Angriffsvektoren hinzufügen, um diesen Kontext zu verbessern.
Beim Untersuchen relevanten Codes verwendet der Agent das Bedrohungsmodell, um die reale Auswirkung zu beurteilen.
Dadurch kann er über Probleme nachdenken, die regelbasierte Scanner isoliert nur schwer verstehen können.
Beispiele können sein:
Der Scanner kann überprüfen:
Wo möglich versucht Codex Security, High-Signal-Probleme in einer isolierten Umgebung zu validieren.
Validierung hilft zu beantworten:
Dieser Schritt zielt darauf ab, Fehlalarme zu reduzieren.
Er garantiert nicht, dass jeder Befund reproduziert wurde, noch dass ein vollständiger Scan beweist, dass ein Repository sicher ist.
Die coverage.json-Datei des Scans dokumentiert, ob der Abdeckungsstatus ist:
Vollständig
Partiell
Unbekannt
Prüfer sollten Ausschlüsse, aufgeschobene Bereiche und offene Punkte lesen, bevor sie einen Scan als Beleg für eine umfassende Prüfung betrachten.
Für akzeptierte Befunde kann Codex Security einen Patch vorschlagen, der auf das aktuelle System zugeschnitten ist.
Das Ziel ist nicht nur, den Scanner zu beruhigen.
Eine gute Korrektur sollte:
Beseitigen oder Abschwächen der Grundursachen.
Codex Security-Scans liefern standardmäßig nur Berichte. Empfohlene Patches sollten weiterhin den normalen Code-Review-, Test- und Bereitstellungskontrollprozessen unterzogen werden.
Die CLI speichert Scanverlauf und unterstützt Feedback zu Erkenntnissen.
Prüfer können Erkenntnisse als falsch positiv markieren und Gründe angeben.
Nachfolgende Scans können diese Erklärung bei der erneuten Prüfung des aktuellen Codes berücksichtigen.
Dies hilft dem Scanner, sich an repositoriumsspezifische Fakten anzupassen, ohne Codepfade dauerhaft zu unterdrücken, die in Zukunft möglicherweise anfällig werden könnten.
OpenAI hat mehrere Adoptions- und Qualitätsdaten aus seinen Vorschaubereitstellungen veröffentlicht.
Dies sind vom Unternehmen gemeldete Kennzahlen, keine unabhängigen Benchmark-Ergebnisse.
OpenAI gab an, dass Codex Security in einem 30-Tage-Zeitraum:
| Kennzahl | Von OpenAI berichtetes Ergebnis |
|---|---|
| Gescannte Commits | Über 1,2 Millionen |
| Kritische Erkenntnisse | 792 |
| Erkenntnisse mit hoher Schwere | 10.561 |
| Gescannte Commits mit kritischen Problemen | Unter 0,1 % |
OpenAI berichtete außerdem über Verbesserungen in der Beta:
OpenAI gab anschließend an, dass die Cloud-Version von Codex Security Folgendes aufweist:
| Kennzahl | Von OpenAI berichtetes Ergebnis |
|---|---|
| Gescannte Codebasen | Über 30.000 |
| Gescannte Commits | Über 30 Millionen |
| Manuell als behoben markierte Erkenntnisse | Über 70.000 |
| Automatisch erkannte | Über 500.000 |
Die Größenordnung ist beträchtlich, diese Zahlen sollten jedoch nicht als kontrollierter Vergleich mit CodeQL, Semgrep, Snyk oder manuellen Penetrationstests interpretiert werden.
Diese Tools funktionieren unterschiedlich und können Erkenntnisse, Korrekturen und Abdeckung auf unterschiedliche Weise messen.
Codex Security ist über mehrere verwandte Schnittstellen verfügbar.
| Schnittstelle | Hauptverwendungszweck |
|---|---|
| Codex Security-Plugin | Interaktive Scans und Korrekturen in der ChatGPT-Desktop-App oder der Codex-CLI |
| Security-Arbeitsplatz | Anzeigen gespeicherter Scans, Erkenntnisse, Repository-Verlauf, Abdeckung und Artefakte |
| Codex Security-CLI | Wiederholbare lokale, Terminal-, Pre-Commit-, Batch- und CI-Workflows |
| TypeScript-SDK | Einbetten von Scan- und Lebenszyklussteuerung in Anwendungen oder Entwicklertools |
| Codex Security-Cloud | Scannen verbundener GitHub-Repositories über die Codex-Cloud |
Die öffentliche CLI und das SDK verwenden denselben allgemeinen Scanner-Workflow wie das Plugin, jedoch können Verfügbarkeit und Funktionsreife zwischen dem Plugin-Verzeichnis, dem CLI-Paket und der Cloud-Forschungspreview variieren.
Die folgenden Befehle folgen der aktuellen offiziellen OpenAI-CLI-Dokumentation.
Die CLI benötigt:
Node.js 22 oder höher
Python 3.10 oder höher
Codex Security-Zugriff
Das GitHub-Repository bietet derzeit spezifischere unterstützte Node.js-Versionsbereiche, einschließlich der neuesten 22.x-, 24.x- und 26.x-Versionen.
Überprüfen Sie Ihre Umgebung:
node --version
python3 --version
Installieren Sie Codex Security von npm:
npm install @openai/codex-security
Überprüfen Sie die installierte Version:
npx @openai/codex-security --version
Listen Sie die Befehle auf:
npx @openai/codex-security --help
Für die lokale interaktive Nutzung melden Sie sich mit einem ChatGPT-Konto an:
npx @openai/codex-security login
Für entfernte oder unbeaufsichtigte Maschinen:
npx @openai/codex-security login --device-auth
Für CI- oder andere unbeaufsichtigte Workflows stellen Sie den API-Schlüssel über die Umgebung bereit:
export OPENAI_API_KEY=""
Geben Sie API-Schlüssel nicht in die Quellcodeverwaltung.
Verwenden Sie einen Schlüsselmanager oder das geschützte Schlüsselsystem der CI-Plattform.
Wenn sowohl eine gespeicherte ChatGPT-Anmeldung als auch ein API-Schlüssel verfügbar sind, wählen Sie die gewünschte Methode explizit aus:
npx @openai/codex-security scan . --auth chatgpt
Oder:
npx @openai/codex-security scan . --auth api-key
Die Authentifizierung gewährt nicht automatisch Trusted Access für Cyber.
OpenAI empfiehlt, Ergebnisse außerhalb des gescannten Repositorys zu speichern.
Berichte können enthalten:
Bereiten Sie Ziel- und Ergebnisverzeichnis vor:
REPOSITORY=/pfad/zum/repository
SCAN_DIR=/pfad/ausserhalb/des/repositorys/codex-security-ergebnisse
Wenn das Standardverzeichnis für den persistenten Status nicht beschreibbar ist, wählen Sie ein anderes privates Verzeichnis:
export CODEX_SECURITY_STATE_DIR=/pfad/ausserhalb/des/repositorys/codex-security-status
Bestätigen Sie vor Beginn der Modellarbeit die lokalen Pfade und die Scan-Konfiguration:
npx @openai/codex-security scan "$REPOSITORY" \
--output-dir "$SCAN_DIR" \
--dry-run
Der Trockenlauf startet Codex nicht und lädt keine Scan-Anmeldeinformationen.
Starten Sie einen Standard-Repository-Scan:
npx @openai/codex-security scan "$REPOSITORY" \
--output-dir "$SCAN_DIR"
Fordern Sie maschinenlesbares JSON-Format auf der Standardausgabe an:
npx @openai/codex-security scan "$REPOSITORY" \
--output-dir "$SCAN_DIR" \
--json
Standardmäßig verwendet Codex Security derzeit:
Modell: gpt-5.6-sol
Inferenzstärke: xhigh
Kostengünstigere Konfigurationen können andere unterstützte Modelle und Stärken verwenden:
npx @openai/codex-security scan "$REPOSITORY" \
--model gpt-5.6-terra \
--effort high
Die unterstützten Intensitätseinstellungen umfassen:
minimal (minimal)
low (niedrig)
medium (mittel)
high (hoch)
xhigh (extrem hoch)
Eine geringere Intensität kann Zeit und Kosten reduzieren, aber auch die Tiefe der Überprüfung verringern.
Das Standard-Ergebnisverzeichnis kann enthalten:
codex-security-results/
├── scan-manifest.json
├── findings.json
├── coverage.json
├── report.md
├── artifacts/
└── exports/
└── results.sarif
report.mdDer primäre, menschenlesbare Bericht.
Beschreibe deine Idee einmal, und We0 AI erstellt eine Showcase-Website, Seiten und ein CMS und hilft nach dem Launch bei Kunden und Traffic.
Eine komplette Projektgeneration zur kostenlosen Registrierung
Am besten geeignet, um einen vollständigen Generierungsablauf auszuprobieren und schnell einen ersten Projektentwurf zu sehen.
findings.jsonStrukturierte Befunde, einschließlich Schweregrad, Konfidenz, betroffener Stellen, Nachweise und Empfehlungen zur Behebung.
coverage.jsonPrüfungsabdeckung, Ausschlüsse, aufgeschobene Arbeiten, offene Probleme und Bewertung der Vollständigkeit.
scan-manifest.jsonZiele, Umfang, Produzenteninformationen und versiegelte Artefaktverweise.
artifacts/Schwachstellenberichte, Proof-of-Concept-Dateien oder relevante Beweise (falls vorhanden).
SARIF kann von GitHub Code Scanning und anderen kompatiblen Sicherheitstools verwendet werden.
Große Monorepos müssen nicht bei jedem Mal vollständig gescannt werden.
Bestimmte Pfade auswählen:
npx @openai/codex-security scan "$REPOSITORY" \
--path services/billing \
--path packages/auth
Dies ist nützlich, wenn eine Veröffentlichung bestimmte Dienste oder Sicherheitsgrenzen betrifft.
Änderungen zwischen der Basis-Revision und HEAD scannen:
npx @openai/codex-security scan "$REPOSITORY" \
--diff origin/main \
--head HEAD
Das Repository-Argument muss auf das Wurzelverzeichnis des Git-Arbeitsbaums zeigen, und die erforderlichen Revisionen müssen lokal vorhanden sein.
Gestaffelte und nicht gestaffelte Änderungen relativ zu HEAD scannen:
npx @openai/codex-security scan "$REPOSITORY" \
--working-tree \
--base HEAD
Dies ist nützlich, bevor ein Pull Request erstellt oder ein Commit mit sicherheitsrelevanten Änderungen durchgeführt wird.
Wenn ein normaler Scan nicht ausreicht, eine umfassendere Überprüfung ausführen:
npx @openai/codex-security scan "$REPOSITORY" \
--mode deep
Der Tiefenmodus dauert länger und kann mehr Modellressourcen verbrauchen.
Die aktuelle OpenAI-Dokumentation besagt, dass Repository- und Pfadziele unterstützt werden, nicht jedoch Diff- oder Arbeitsbaum-Ziele.
Interne Dokumentation bereitstellen, damit der Agent das System korrekt versteht:
npx
@openai/codex-security scan "$REPOSITORY" \
--knowledge-base /path/to/architecture.md \
--knowledge-base /path/to/security-policies
Nützlicher Kontext kann umfassen:
Vertrauliche Informationen nicht unnötig einschließen.
Diese Dateien sind Teil eines sicherheits sensitiven Scan-Workflows und sollten angemessenen Aufbewahrungs- und Zugriffskontrollen unterliegen.
Ein geschätztes Modellkostenlimit in US-Dollar festlegen:
npx @openai/codex-security scan "$REPOSITORY" \
--max-cost 5
Bereits laufende Anfragen können nach Erreichen des Limits noch abgeschlossen werden, sodass der endgültige Betrag den Schwellenwert überschreiten kann.
Wenn ein kostenbegrenzter Scan gestoppt wird, behält Codex Security die vorhandenen Ergebnisse.
Teilergebnisse sollten nicht als vollständige Repository-Abdeckung betrachtet werden.
Den mitgelieferten Git-Hook installieren:
npx @openai/codex-security install-hook
Dieser Hook scannt gestaffelte und nicht gestaffelte Änderungen vor dem Commit.
OpenAI gibt an, dass er blockiert:
Er ersetzt keine vorhandenen Pre-Commit-Skripte.
Teams sollten überprüfen, wie er mit lokaler Leistung, Entwicklerzugriff, Modellkosten und bestehenden Lint- oder Test-Hooks interagiert, bevor sie ihn organisationsweit aktivieren.
Zuerst die GitHub-CLI verifizieren:
gh auth login
Den interaktiven Repository-Erkennungsprozess starten:
npx @openai/codex-security bulk-scan
Der aktuelle interaktive Prozess schließt archivierte Repositories und Forks aus und verlangt vor dem Scan eine Bestätigung.
Für wiederholbare Scan-Aktivitäten eine vorbereitete CSV-Liste verwenden:
npx @openai/codex-security bulk-scan repositories.csv \
--output-dir /path/outside/repositories/security-scans \
--workers 4
Dasselbe Kommando erneut auszuführen, kann die Scan-Aktivität fortsetzen, ohne Repositories erneut zu scannen, die bereits vollständige Ergebnisartefakte besitzen.
Das öffentliche Repository enthält Docker- und Compose-Ressourcen.
Bei Kontozugriff mit den erforderlichen Images und Umgebungen lautet ein Beispiel-Batch-Befehl:
docker compose run --rm codex-security \
bulk-scan /input/repositories.csv \
--output-dir /output \
--workers 4
OpenAI empfiehlt:
Containerisierung reduziert die Host-Exposition teilweise, macht autorisierte Sicherheitsscans jedoch nicht risikofrei.
Frühere Scans eines Repositories auflisten:
npx @openai/codex-security scans list "$REPOSITORY"
Gespeicherte Scans überprüfen:
npx @openai/codex-security scans show SCAN_ID
Überprüfte Befunde als Fehlalarme markieren:
npx @openai/codex-security findings false-positive FINDING_OCCURRENCE_ID \
--reason "Diese Route hat die Berechtigungen bereits geprüft"
Einen gespeicherten Scan mit seinen ursprünglichen Einstellungen erneut ausführen
Konfiguration:
npx @openai/codex-security scans rerun SCAN_ID
Befunde nach Grundursache abgleichen:
npx @openai/codex-security scans match
PREVIOUS_SCAN_ID CURRENT_SCAN_ID
Scan-Ergebnisse vergleichen:
```Bash
npx @openai/codex-security scans compare PREVIOUS_SCAN_ID CURRENT_SCAN_ID
Der Vergleich kann Ergebnisse wie folgt einstufen:
Wenn ein nachfolgender Scan den relevanten Bereich nicht abdeckt, bleiben fehlende Ergebnisse im Status „Unbekannt“.
Dasselbe npm-Paket enthält ein ECMAScript-Modul-TypeScript-SDK.
Es erfordert serverseitig Node.js 22 oder höher sowie für Scans Python 3.10 oder höher.
Eine grundlegende Integration sieht wie folgt aus:
import { CodexSecurity } from "@openai/codex-security";
const security = new CodexSecurity();
try {
const result = await security.run("/path/to/repository", {
outputDir: "/path/outside/repository/results",
});
console.log(result.reportPath);
console.log(result.coverage.completeness);
console.log(result.findings.findings.length);
} finally {
await security.close();
}
Das SDK unterstützt langlebige Workflows durch folgende Funktionen:
Wiederverwendbare Anwendungen sollten einen Client erstellen, die gewünschten Scans ausführen und den Client schließen, um die isolierte Laufzeitumgebung freizugeben.
Der offizielle CI-Leitfaden von OpenAI demonstriert die Verwendung von GitHub Actions für Pull-Request-Scans.
Das empfohlene Muster ist:
Das offizielle Beispiel sperrt eine bestimmte zum Veröffentlichungszeitpunkt verfügbare Paketversion. Teams sollten diese Version bewusst nach Prüfung der Versionshinweise aktualisieren, anstatt ungeprüfte Sicherheitstools automatisch mit Repository-Geheimnissen auszuführen.
Eine kompakte Darstellung des Kern-Scanschritts sieht wie folgt aus:
- name: Pull-Request-Änderungen scannen
env:
OPENAI_API_KEY: ${{ secrets.CODEX_SECURITY_API_KEY }}
BASE_SHA: ${{ github.event.pull_request.base.sha }}
HEAD_SHA: ${{ github.event.pull_request.head.sha }}
SCAN_DIR: ${{ runner.temp }}/codex-security-results
run: |
set -euo pipefail
BASE_REVISION="$(git merge-base "$BASE_SHA" "$HEAD_SHA")"
"$CODEX_SECURITY_BIN" scan . \
--diff "$BASE_REVISION" \
--head "$HEAD_SHA" \
--auth api-key \
--output-dir "$SCAN_DIR" \
--json > "$RUNNER_TEMP/codex-security.json"
Dieser Auszug setzt voraus, dass der Runner die CLI installiert und verifiziert hat, den Pull-Request-Head mit vollständiger Historie ausgecheckt hat und CODEX_SECURITY_BIN definiert ist.
Für Produktionsworkflows verwenden Sie den vollständigen offiziellen CI-Leitfaden, einschließlich fixierter Aktionen, SARIF-Export, Berechtigungen, Artefaktaufbewahrung und Branch-Sicherheitsprüfungen.
Codex Security soll nicht alle bestehenden Sicherheitskontrollen ersetzen.
Es kann folgende Tools ergänzen:
Sein besonderer Vorteil liegt in der kontextuellen Schlussfolgerung über Repository-Strukturen und Systemabsichten hinweg.
Eine ausgereifte Sicherheitsarchitektur kann deterministische Scanner für hochvolumige bekannte Muster und agentenbasierte Scanner für dateiübergreifende Logik, Exploitability-Analysen, Beweise und Behebungsempfehlungen verwenden.
Kein Scanner kann nachweisen, dass in einer beliebigen realen Codebasis keine Schwachstellen existieren.
Teilabdeckung oder unbekannte Abdeckung machen diese Einschränkung noch bedeutsamer.
Einige Ergebnisse können in isolierten Umgebungen getestet werden.
Andere hängen ab von:
Ein Ergebnis ohne automatisierte Verifikation ist nicht automatisch ein False Positive, und eine verifizierte Bestätigung deckt auch nicht alle Varianten dieser Schwachstelle auf.
Das Modell kann Architekturen missverstehen, Auswirkungen überschätzen, unvollständige Patches vorschlagen oder Regressionen einführen.
Sicherheitsverantwortliche sollten Beweise und Behebungsvorschläge prüfen.
Der Paketquellcode ist öffentlich, aber der Standardscan ist keine vollständig lokale statische Binärdatei ohne Inferenzzugriff.
Die Modellnutzung kann Kosten, Datenverarbeitungs- und Autorisierungsaspekte mit sich bringen.
Das Ergebnisverzeichnis kann sensibler sein als normale Build-Ausgaben.
Laden Sie keine detaillierten Ergebnisse, Proof-of-Concept-Dateien oder Schwachstellen-Codeauszüge in öffentliche Artefakte hoch.
Verwenden Sie das Tool nur für Repositories und Systeme, die Ihnen gehören oder für die Sie ausdrücklich zur Bewertung autorisiert sind.
Die Zugriffskontrollen von OpenAI ersetzen keine rechtliche Autorisierung.
Der größte konzeptionelle Vorteil von Codex Security ist zugleich eine praktische Anforderung.
Der Agent benötigt genauen Kontext.
Allein das Repository erklärt möglicherweise nicht:
Schlechter Kontext kann zu schlechter Ergebnisqualität führen.
Teams sollten editierbare Bedrohungsmodelle und Wissensdatenbanken als erstklassige Sicherheitsressourcen betrachten – nicht als optionale Prompt-Dekoration.
Codex Security ist der Anwendungssicherheits-Agent von OpenAI zum Erkennen, Verifizieren, Priorisieren und Beheben von Schwachstellen. Er entstand aus dem internen Projekt Aardvark und ist nun verfügbar.
Umgesetzt über Plugins, CLI, TypeScript-SDK und cloudbasierte Workflows, die Repositories verbinden.
CLI und TypeScript-SDK sind auf GitHub unter Apache 2.0 verfügbar.
Die Lizenz wird öffentlich veröffentlicht. Die zugrunde liegenden OpenAI-Modelle, der verwaltete Cloud-Dienst, geschützte Scan-Ergebnisse sowie der uneingeschränkte Cybersicherheitszugriff wurden nicht als Open-Source- oder Open-Weight-Komponenten veröffentlicht.
Jeder kann auf die öffentlichen Pakete zugreifen, aber für die Ausführung von Scans ist ein Codex-Security-Zugriff erforderlich. Einige Repository-weite Scans oder erweiterte Netzwerkfunktionen können zusätzlich einen „Trusted Access for Cyber" erfordern.
Die aktuellen CLI-Dokumentationen geben an, dass Scans standardmäßig GPT-5.6 Sol mit einer Inferenz-Anstrengungsstufe von xhigh verwenden. Benutzer können andere unterstützte Modelle und Anstrengungsstufen wählen; für öffentliche Repositories sind zudem ausgewählte Konfigurationen von Drittanbietern dokumentiert.
Ja. Die CLI kann Änderungen scannen, die zwischen der Basis-Revision und der Head-Revision committet wurden, und eignet sich daher für Pull-Request-Workflows. OpenAI bietet außerdem offizielle GitHub-Actions-Anleitungen mit Unterstützung für SARIF-Export und Artefakt-Aufbewahrung.
Es kann begrenzte Reparaturvorschläge unterbreiten und dabei helfen zu überprüfen, ob eine Änderung ein Scan-Ergebnis behebt. Scans erzeugen standardmäßig nur Berichte; Menschen sollten Patches vor dem Merge oder Deployment prüfen, testen und genehmigen.
Das Repository enthält Docker- und Docker-Compose-Ressourcen für nicht-interaktive Batch-Scans. OpenAI empfiehlt privaten persistenten Speicher, Schlüsselverwaltung, unterstützte Linux-Isolationsfunktionen sowie optional eine Härtung mit AppArmor.
Nein. Die Abdeckung kann vollständig, teilweise oder unbekannt sein, und kein automatischer Scanner kann garantieren, dass komplexe Anwendungen frei von Schwachstellen sind. Nutzen Sie Codex Security als Teil eines umfassenderen Programms für sichere Entwicklung.
OpenAI hat die Codex-Security-CLI und das TypeScript-SDK als Open Source veröffentlicht und bietet Entwicklern eine öffentliche, auf Apache-2.0 basierende Grundlage für Repository-Scans, Änderungsprüfungen, Scan-Verlauf, Fix-Validierung, Batch-Aktivitäten, SARIF-Export, CI-Prüfungen und benutzerdefinierte Sicherheitsintegrationen.
Der Agent unterscheidet sich von einfachen Muster-Scannern: Er erstellt Repository-Kontext und Bedrohungsmodelle, sucht in diesem Kontext nach Schwachstellen, validiert verdächtige Probleme so weit wie möglich und schlägt begrenzte Fixes für die menschliche Überprüfung vor.
Diese Veröffentlichung ist kein uneingeschränktes lokales Sicherheitsmodell. Für die Ausführung von Scans ist weiterhin ein autorisierter Inferenzzugriff erforderlich, und einige erweiterte Cybersicherheits-Workflows können „Trusted Access for Cyber" voraussetzen. Sensible Scan-Ergebnisse und Quellcode-Ausschnitte erfordern zudem sorgfältige Speicher- und Aufbewahrungskontrollen.
Codex Security ist am nützlichsten in einem mehrschichtigen Anwendungssicherheitsprogramm – nicht als Nachweis dafür, dass ein Repository frei von Schwachstellen ist.
Der eigentliche Unterschied besteht darin, dass Sicherheitsprüfungen nun näher an der Geschwindigkeit der KI-gestützten Entwicklung liegen können, sofern Teams Autorisierung, Bedrohungsmodellierung, Validierung und menschliche Genehmigung konsequent in ihren Prozessen umsetzen.
Starte mit einem Satz und erhalte in wenigen Minuten eine vollständige Website.
