OpenAI veröffentlicht Open-Source-Codex-Security: So scannen, verifizieren und beheben Sie Schwachstellen

Einleitung

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:

• Codebasen auf Schwachstellen zu scannen.
• Sinnvolle Befunde zu validieren.
• Änderungen vor dem Zusammenführen von Code zu überprüfen.
• Befunde über mehrere Scans hinweg zu verfolgen.
• Falschmeldungen zu markieren und sich zu merken.
• Zu validieren, ob Korrekturen das ursprüngliche Problem beheben.
• Strukturierte Ergebnisse für die Automatisierung zu exportieren.
• Sicherheitsüberprüfungen in CI/CD-Workflows zu integrieren.
• Über das TypeScript-SDK benutzerdefinierte Sicherheitstools zu erstellen.

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.

Von Aardvark zu Codex Security

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:

• Codebasen lesen.
• Modelle davon erstellen, wie Systeme funktionieren.
• Neue Commits untersuchen.
• Über Ausnutzbarkeit nachdenken.
• Tests schreiben und ausführen.
• Sicherheitstools verwenden.
• Schwachstellen erklären.
• Gezielte Patch-Vorschläge unterbreiten.

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.

Was tatsächlich als Open Source veröffentlicht wurde

Das öffentliche GitHub-Repository enthält:

• Die Codex Security-CLI.
• Das TypeScript-SDK.
• Docker- und Docker-Compose-Ressourcen.
• CI-fähige Befehle und Unterstützung für strukturierte Ausgaben.
• Scan-Verlauf und Verwaltung von Befunden.
• Dokumentation und Beitragsdateien.

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.

Was nicht als offenes Modell enthalten ist

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.

Open Source hebt Zugriffskontrollen nicht auf

Die Installation des npm-Pakets bedeutet nicht, dass Sie die Erlaubnis erhalten, jeden Scan auszuführen.

Die Dokumentation von OpenAI stellt klar:

• Codex Security-Zugriff ist erforderlich.
• Bestimmte Repositories oder Anfragen erfordern möglicherweise „Trusted Access for Cyber“.
• Das Anmelden oder Festlegen eines API-Schlüssels gewährt automatisch keinen „Trusted Access“.
• Sicherheitsbefunde können sensible Quellcode-Auszüge und Details zur Exploit-Ausnutzung enthalten.
• Benutzer sollten nur Code scannen, den sie besitzen oder zu dessen Bewertung sie berechtigt sind.

Der öffentliche Code macht den Workflow überprüfbar und erweiterbar. Er entfernt nicht die Sicherheits- und Autorisierungsebenen rund um erweiterte Netzwerkzwecke.

Warum diese Veröffentlichung wichtig ist

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:

• Manueller Bedrohungsmodellierung.
• Statischer Analyse-Konfiguration.
• Penetrationstests.
• Abhängigkeitsprüfungen.
• Manueller Triage.
• Release-Planung.
• Verfügbarkeit von Sicherheitsteams.

Das Problem ist nicht nur, dass Entwickler keine Schwachstellenberichte haben.

Viele Maintainer erhalten bereits zu viele Berichte, darunter:

• Doppelte Befunde.
• Warnungen mit geringer Auswirkung.
• Falsche Schweregradeinstufungen.
• Unerreichbare Codepfade.
• Befunde ohne Nachweise.
• Vage Korrekturvorschläge.
• Berichte, die die Projektarchitektur ignorieren.

Codex Security ist um das gegenteilige Ziel herum entworfen: weniger, kontextreichere Befunde mit Beweisen, die Prüfern helfen zu entscheiden, was behoben werden sollte.

Wie Codex Security funktioniert

OpenAI beschreibt das System als mehrstufigen Anwendungssicherheits-Workflow.

1. Repository-Kontext und Bedrohungsmodell aufbauen

Codex Security untersucht zunächst das Repository, um die sicherheitsrelevanten Strukturen im Projekt zu verstehen.

Es versucht zu identifizieren:

• Was das System tut.
• Welche Komponenten einander vertrauen.
• Wo benutzergesteuerte Eingaben hereinkommen.
• Welche Grenzen Benutzer, Mandanten, Rollen oder Dienste voneinander trennen.
• Welche Operationen privilegiert sind.
• Welche Vermögenswerte sensibel sind.
• Wo das System Angreifern ausgesetzt ist.

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.

1. Schwachstellen im Kontext suchen

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:

• Autorisierungslücken über Mandantengrenzen hinweg.
• Indirekte Prompt-Injektion, die auf privilegierte Tools zugreift.
• Offenlegung sensibler Daten über Proxy-Verfolgung.
• Authentifizierungsumgehung.
• Server-Side Request Forgery.
• Gefährliche Interaktionen zwischen ansonsten gewöhnlichen Komponenten.

Der Scanner kann überprüfen:

• Das gesamte Codespeicher-Repository.
• Einen oder mehrere ausgewählte Pfade.
• Einen Commit-Bereich.
• Pull-Request-Änderungen.
• Gestaffelte und nicht gestaffelte Arbeitsverzeichnisänderungen.
• Mehrere Repositories in Batch-Aktivitäten.

1. Sinnvolle Befunde validieren

Wo möglich versucht Codex Security, High-Signal-Probleme in einer isolierten Umgebung zu validieren.

Validierung hilft zu beantworten:

• Ist der verwundbare Pfad erreichbar?
• Sind die vorgeschlagenen Ausnutzungsbedingungen realistisch?
• Funktioniert der Proof of Concept?
• Wurde das Problem falsch klassifiziert?
• Könnte der Befund ein laufendes System beeinträchtigen?

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.

1. Gezielte Korrekturen vorschlagen

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.

• Beabsichtigtes Anwendungsverhalten beibehalten.
• Weitreichende, nicht damit zusammenhängende Refaktorierungen vermeiden.
• Regressionen minimieren.
• Gegebenenfalls Beweise oder Tests einbeziehen.
• Für menschliche Ingenieure überprüfbar bleiben.

Codex Security-Scans liefern standardmäßig nur Berichte. Empfohlene Patches sollten weiterhin den normalen Code-Review-, Test- und Bereitstellungskontrollprozessen unterzogen werden.

1. Aus Überprüfungsfeedback lernen

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.

Von OpenAI berichtete Ergebnisse

OpenAI hat mehrere Adoptions- und Qualitätsdaten aus seinen Vorschaubereitstellungen veröffentlicht.

Dies sind vom Unternehmen gemeldete Kennzahlen, keine unabhängigen Benchmark-Ergebnisse.

Forschungspreview März 2026

OpenAI gab an, dass Codex Security in einem 30-Tage-Zeitraum:

OpenAI berichtete außerdem über Verbesserungen in der Beta:

• In einem kontinuierlich gescannten Repository gingen unnötige Warnungen um 84 % zurück.
• Erkenntnisse mit überhöhter Schwere gingen um über 90 % zurück.
• Falsch positive Ergebnisse in verschiedenen Repositories gingen um über 50 % zurück.

Daybreak-Update Juni 2026

OpenAI gab anschließend an, dass die Cloud-Version von Codex Security Folgendes aufweist:

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-Schnittstellen

Codex Security ist über mehrere verwandte Schnittstellen verfügbar.

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.

Schnellstart: Codex Security installieren und ausführen

Die folgenden Befehle folgen der aktuellen offiziellen OpenAI-CLI-Dokumentation.

Schritt 1: Voraussetzungen prüfen

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

Schritt 2: Paket installieren

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

Schritt 3: Authentifizierung

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.

Schritt 4: Privates Ausgabeverzeichnis wählen

OpenAI empfiehlt, Ergebnisse außerhalb des gescannten Repositorys zu speichern.

Berichte können enthalten:

• Quellcode-Auszüge.
• Schwachstellennachweise.
• Proof-of-Concept-Materialien.
• Architekturdetails.
• Sensible Pfade.
• Korrekturanleitungen.

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

Schritt 5: Trockenlaufprüfung ausführen

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.

Schritt 6: Ersten Scan ausführen

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.

Ergebnisse eines vollständigen Scans

Das Standard-Ergebnisverzeichnis kann enthalten:

codex-security-results/
├── scan-manifest.json
├── findings.json
├── coverage.json
├── report.md
├── artifacts/
└── exports/
└── results.sarif

report.md

Der primäre, menschenlesbare Bericht.

findings.json

Strukturierte Befunde, einschließlich Schweregrad, Konfidenz, betroffener Stellen, Nachweise und Empfehlungen zur Behebung.

coverage.json

Prüfungsabdeckung, Ausschlüsse, aufgeschobene Arbeiten, offene Probleme und Bewertung der Vollständigkeit.

scan-manifest.json

Ziele, Umfang, Produzenteninformationen und versiegelte Artefaktverweise.

artifacts/

Schwachstellenberichte, Proof-of-Concept-Dateien oder relevante Beweise (falls vorhanden).

SARIF-Export

SARIF kann von GitHub Code Scanning und anderen kompatiblen Sicherheitstools verwendet werden.

Nur wichtige Bereiche scannen

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.

Pull Requests oder Commit-Bereiche überprüfen

Ä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.

Nicht committete Änderungen überprüfen

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.

Tiefen-Scan-Modus verwenden

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.

Kontextarchitektur und Sicherheitsinformationen hinzufügen

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:

• Vertrauensgrenzen.
• Authentifizierungsarchitektur.
• Mandantentrennungsregeln.
• Klassifizierung sensibler Daten.
• Erwartete Netzwerkpfade.
• Sicherheitsinvarianten.
• Bedrohungsmodelle.
• Bekannte Ausnahmen.
• Kompensierende Kontrollen.

Vertrauliche Informationen nicht unnötig einschließen.

Diese Dateien sind Teil eines sicherheits sensitiven Scan-Workflows und sollten angemessenen Aufbewahrungs- und Zugriffskontrollen unterliegen.

Scan-Kosten steuern

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.

Vor-Commit-Sicherheitsprüfung hinzufügen

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:

• Befunde mit hohem Schweregrad.
• Scan-Fehler.

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.

Mehrere Repositories scannen

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.

Batch-Scans in Docker ausführen

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:

• Einen Linux-Docker-Host zu verwenden.
• Nichtprivilegierte Benutzer-Namespaces zu unterstützen.
• Private persistente Verzeichnisse für Ergebnisse und Anmeldestatus zu verwenden.
• Geheimnisse über Umgebung oder Schlüsselverwaltung bereitzustellen.
• Optional AppArmor-Härtung zu aktivieren, wo unterstützt.

Containerisierung reduziert die Host-Exposition teilweise, macht autorisierte Sicherheitsscans jedoch nicht risikofrei.

Befunde über Läufe hinweg verfolgen

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:

• Neu.
• Fortbestehend.
• Wiedereröffnet.
• Behoben.
• Unbekannt.

Wenn ein nachfolgender Scan den relevanten Bereich nicht abdeckt, bleiben fehlende Ergebnisse im Status „Unbekannt“.

Verwendung des TypeScript-SDK

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:

• Vorabprüfungen.
• Typisierte Ergebnisse.
• Abdeckungsdetails.
• Fortschritts-Callbacks.
• Geschätzte Kostenlimits.
• Abbruchvorgänge.
• Scan-Lebenszyklusverwaltung.
• Zugriff auf Artefaktpfade.

Wiederverwendbare Anwendungen sollten einen Client erstellen, die gewünschten Scans ausführen und den Client schließen, um die isolierte Laufzeitumgebung freizugeben.

Hinzufügen von Codex Security zu CI

Der offizielle CI-Leitfaden von OpenAI demonstriert die Verwendung von GitHub Actions für Pull-Request-Scans.

Das empfohlene Muster ist:

1. Speichern Sie den API-Schlüssel als geschütztes Repository- oder Organisationsgeheimnis.
2. Installieren Sie Codex Security außerhalb des Repository-Checkout-Verzeichnisses.
3. Sperren Sie die Paketversion.
4. Checken Sie die vollständige Git-Historie aus, ohne Checkout-Anmeldedaten zu behalten.
5. Berechnen Sie die Merge-Basis.
6. Scannen Sie nur den Diff des Pull-Requests.
7. Exportieren Sie SARIF.
8. Laden Sie SARIF in GitHub Code Scanning hoch.
9. Behalten Sie Scan-Artefakte.
10. Fügen Sie Schweregrad-Richtlinien erst nach Prüfung der Scan-Qualität und Laufzeit hinzu.

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.

Wo Codex Security in der Sicherheitsarchitektur steht

Codex Security soll nicht alle bestehenden Sicherheitskontrollen ersetzen.

Es kann folgende Tools ergänzen:

• Statische Anwendungssicherheitstests.
• Software-Compound-Analyse.
• Secret-Scanning.
• Infrastruktur-als-Code-Scans.
• Container-Scans.
• Abhängigkeitsaktualisierungen.
• Fuzzing.
• Dynamische Anwendungstests.
• Manuelle Code-Reviews.
• Penetrationstests.
• Bug-Bounty-Programme.
• Produktionsüberwachung.

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.

Was Codex Security nicht garantieren kann

Es kann nicht beweisen, dass ein Repository sicher ist

Kein Scanner kann nachweisen, dass in einer beliebigen realen Codebasis keine Schwachstellen existieren.

Teilabdeckung oder unbekannte Abdeckung machen diese Einschränkung noch bedeutsamer.

Verifikation ist nicht universell anwendbar

Einige Ergebnisse können in isolierten Umgebungen getestet werden.

Andere hängen ab von:

• Produktionsdaten.
• Externen Diensten.
• Infrastrukturkonfigurationen.
• Hardware.
• Anmeldedaten.
• Geschäftslogik.
• Nutzerverhalten.

Ein Ergebnis ohne automatisierte Verifikation ist nicht automatisch ein False Positive, und eine verifizierte Bestätigung deckt auch nicht alle Varianten dieser Schwachstelle auf.

KI-Ergebnisse erfordern weiterhin menschliche Überprüfung

Das Modell kann Architekturen missverstehen, Auswirkungen überschätzen, unvollständige Patches vorschlagen oder Regressionen einführen.

Sicherheitsverantwortliche sollten Beweise und Behebungsvorschläge prüfen.

Das Open-Source-Paket ruft weiterhin das Modell auf

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.

Sensible Ausgaben müssen geschützt werden

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.

Netzwerkzugriff ist beschränkt zu verwenden

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.

Auch Sicherheitsscanner brauchen ein Bedrohungsmodell

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:

• Welcher Dienst öffentlich zugänglich ist.
• Welchem Identitätsanbieter vertraut wird.
• Ob Netzwerkgrenzen existieren.
• Welche Daten sensibel sind.
• Welche Autorisierungsprüfungen vorgelagert durchgeführt werden.
• Welche Bereitstellungsfunktion deaktiviert ist.
• Welche Risiken die Organisation akzeptiert.

Schlechter Kontext kann zu schlechter Ergebnisqualität führen.

Teams sollten editierbare Bedrohungsmodelle und Wissensdatenbanken als erstklassige Sicherheitsressourcen betrachten – nicht als optionale Prompt-Dekoration.

Häufig gestellte Fragen

Was ist Codex Security?

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.

Ist Codex Security vollständig Open Source?

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.

Kann jeder Codex Security installieren und ausführen?

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.

Welches Modell verwendet Codex Security?

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.

Kann Codex Security Pull-Requests scannen?

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.

Behebt Codex Security Schwachstellen automatisch?

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.

Kann Codex Security in Docker ausgeführt werden?

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.

Beweist ein sauberer Codex-Security-Bericht, dass meine Anwendung sicher ist?

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.

Verwandte Werkzeuge

• Codex Security: Offizieller Überblick über Plugins, CLI, SDK, Cloud-Scanner und unterstützte Workflows.
• Codex Security GitHub-Repository: Apache-2.0-Quellcode für CLI, TypeScript-SDK, Docker-Ressourcen und Beitrags-Workflows.
• Codex Security auf npm: Veröffentlichtes Paket zur Installation von CLI und SDK.
• Codex CLI: Open-Source-lokaler Coding-Agent und Plugin-Host von OpenAI.
• GitHub-Code-Scannen: SARIF-kompatible Schnittstelle für Schwachstellen-Ergebnisse von GitHub.
• CodeQL: Semantische Codeanalyse-Engine von GitHub für abfragebasierte Schwachstellenerkennung.
• Semgrep: Regelbasiertes statisches Analyse-Tool, das agentenbasierte Sicherheitsprüfungen ergänzen kann.
• OWASP Juice Shop: Eine absichtlich verwundbare Anwendung für autorisierte Sicherheitsschulungen und Scanner-Evaluierungen.

Verwandte Links

• Codex Security Dokumentation: Offizieller Ausgangspunkt für Produktschnittstellen und Workflows.
• Codex Security CLI-Schnellstart: Offizielle Anweisungen zu Installation, Authentifizierung, Scans, Verlauf, Budget, Batch-Operationen und Docker.
• Codex Security TypeScript SDK: Offizielle SDK-Dokumentation zu Einrichtung, Scan-Lebenszyklus, typisierten Ergebnissen, Fortschritt und Abbruch.
• Codex Security in CI ausführen: Vollständige GitHub-Actions- und SARIF-Workflows von OpenAI.
• Codex Security Forschungsvorschau: OpenAIs Veröffentlichungsartikel vom März 2026 mit Vorschau-Kennzahlen.
• Einführung von Aardvark: Ursprüngliche Beschreibung des intelligenten Sicherheitsforschers, aus dem Codex Security hervorging.
• Daybreak-Sicherheitsinitiative: OpenAIs Update vom Juni 2026 zu Codex-Security-Umfang, Open-Source-Sicherheitsarbeit und defensiven Cyber-Tools.

Zusammenfassung

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.