Vulnerability Scanner mit Codex Security: Cloud, PRs und CI

Codex Security als Vulnerability Scanner: Was nach DevDay möglich ist

Codex Security prüft potenziell verwundbaren Code an drei Stellen: im Repository, im Pull Request und in der lokalen Arbeitskopie. Das lässt sich mit einer Gebäudeprüfung, der Prüfung eines geplanten Umbaus und einer Kontrolle vor dem Verlassen der Baustelle vergleichen. Jede davon erfasst einen anderen Ausschnitt desselben Systems.

Ein Pull Request ist eine vorgeschlagene Codeänderung, die noch geprüft werden muss. Die CLI ist das Befehlszeilenwerkzeug für das Terminal; CI bezeichnet die automatisierten Prüfungen, die bei Codeänderungen laufen.

Cloud untersucht Befunde, entfernt Duplikate und bereitet Korrekturen vor, während der eigene Rechner ausgeschaltet ist. OpenAI führt das Angebot weiterhin als Research Preview. Die DevDay-Ankündigung vom 29. September ergänzt Angaben zur Planung von Scans und zur Verfügbarkeit. Sie macht Cloud noch nicht zu einem allgemein verfügbaren Produkt. DevDay-Rückblick, aktueller Produktstatus.

Für GitLab-Teams ist die CLI der richtige Einstieg. Die aktuelle Einrichtung von Security Cloud bindet GitHub an. Dass Codex grundsätzlich GitLab-Merge-Requests unterstützt, belegt keine GitLab-Unterstützung für Security Cloud. Die separate Anleitung für GitLab CI/CD beschreibt einen unterstützten Weg, Sicherheitsprüfungen in dieser Umgebung auszuführen.

In welchen Tarifen ist der Zugang enthalten, und was kosten fünf Personen?

Pro, Business, Enterprise und Edu erhalten Zugang zu Codex Security Cloud, laut der datierten DevDay-Ankündigung und dem aktuellen Help Center. Security Review nennt dieselben Tarife und schließt Plus ausdrücklich aus. Die Berechtigungen im Workspace und der Repository-Zugriff müssen dennoch freigeschaltet werden. Verfügbarkeit von Cloud, Zugang zu Security Review.

Für ein kleines Unternehmen bietet sich der Abovergleich anhand von fünf Standard-Business-Lizenzen an:

Bei tokenbasierter Abrechnung richten sich die Kosten danach, wie viel das Modell liest und erzeugt. Die Lizenzpreise können je nach Land und Währung abweichen. Die Aborechnung basiert auf den aktuellen Business-FAQ. Laut den aktuellen Abrechnungshinweisen zu Cloud werden bestehende Kunden informiert und müssen zustimmen, bevor kostenpflichtige Nutzung beginnt. Ohne hinterlegte Finanzierung pausieren die Scans. Ein Gesamtpreis für Scans eines Teams mit fünf Personen wird dort nicht genannt. Cloud-Abrechnung, Unterschied zwischen Abo- und API-Preisen.

Bei einem bereits laufenden Business-Abo können die zusätzlichen Lizenzkosten null betragen. Die Nutzung für Scans und Reviews gehört trotzdem ins Budget. Die monatliche Gesamtrechnung setzt sich aus den Lizenzen, gegebenenfalls Cloud-Nutzung, API-basierten CI-Scans, Runner-Laufzeit und einem optionalen Abo für ein Sicherheitsdashboard zusammen.

Ein neuer kostenloser erster Monat gehört nicht in die Kalkulation. Das Angebot zur kostenlosen Nutzung war an den Start am 6. März gebunden und galt für den anschließenden Monat. Die aktuellen Produkt- und Abrechnungsseiten belegen kein erneuertes Angebot zum 30. September. Ursprüngliche Startbedingungen, aktuelle Abrechnungsbedingungen.

Als Preisvergleich: Semgrep nennt für sein kostenpflichtiges Produkt Code $30 pro mitwirkender Person und Monat, also $150 für fünf Personen. Die Free Edition unterstützt außerdem bis zu 10 Repositories und 10 Mitwirkende. Ein Team mit fünf Personen kann somit beide Angebote erproben, ohne davon auszugehen, dass jeder bestehende Scanner kostenpflichtig ist. Da die Angebote unterschiedliche Prüfbereiche abdecken, sollte der Preisvergleich allein nicht über die Sicherheitswerkzeuge entscheiden. Semgrep-Preise.

Ein Repository anbinden und die Korrektur prüfen

Der Einstieg gelingt am besten mit einer vertrauten Anwendung und einer Person, die deren Zugriffsregeln erklären kann. Ein Bedrohungsmodell beschreibt knapp, was die Anwendung schützt, wer darauf zugreifen kann und an welchen Stellen sie einem anderen System vertraut. Es ist der Bauplan, an dem der Prüfer erkennt, welche Türen verschlossen sein sollten.

1. In ChatGPT auf dem Desktop oder im Web Plugins öffnen. Codex Security Cloud installieren und aktivieren, anschließend Security Cloud öffnen.
2. New scan wählen. Falls dazu aufgefordert, GitHub verbinden und Zugriff auf das zu prüfende Repository gewähren.
3. Das Repository und eine kompatible Cloud environment auswählen. Bei Bedarf eine Umgebung mit den erforderlichen Abhängigkeiten und der Testkonfiguration des Projekts erstellen.
4. Unter What to scan den Eintrag Repository wählen, anschließend Start scan. Der Fortschritt erscheint unter Scans.
5. Findings öffnen. Den betroffenen Code, die Validierungsbelege und die Hinweise zur Behebung lesen. Ein gescheiterter Validierungsversuch lässt die Beweislage offen; er entkräftet die Schwachstelle nicht.
6. Wo Fix with Codex angeboten wird, den Patch erzeugen und prüfen. Nach der Prüfung mit Create draft pull request einen Entwurf anlegen. Vor dem Merge die üblichen Tests ausführen und die für den Code verantwortliche Person einbeziehen.

Dies sind die aktuellen Bedienelemente zur Cloud-Einrichtung. Mit der Umgebung lassen sich vermutete Fehler leichter reproduzieren. Sie garantiert jedoch nicht, dass jedes Problem validiert wird. Verhalten bei der Validierung.

Für laufende Prüfungen einen weiteren Scan mit Commit changes anlegen. Unter Repositories die Monitoring settings öffnen, um die Umgebung zu wählen, den berücksichtigten Zeitraum der Historie festzulegen und die Überwachung zu aktivieren oder zu pausieren. Ändert sich die Architektur, das Bedrohungsmodell unter Project context anpassen. Cloud unterstützt außerdem geplante Repository-Scans, wie bei DevDay beschrieben. Die aktuelle Einrichtungsanleitung nennt jedoch weder Intervalle noch Kontingente; ein Anspruch auf tägliche Scans lässt sich daraus nicht ableiten. Überwachung einrichten, geplante Scans.

Gogs als Praxisfall: Befunde nach Relevanz einordnen

Gogs zeigt, warum der konkrete Betriebskontext geklärt werden muss, bevor aus einem Befund ein Ticket wird. OpenAI nennt dieses Repository und die folgenden Schwachstellen unter den veröffentlichten Entdeckungen von Codex Security. Es handelt sich um einen vom Anbieter veröffentlichten Scan-Fall; für diesen Artikel wurde kein neuer Scan durchgeführt. Die folgenden Empfehlungen zur Einordnung stützen sich auf die Sicherheitshinweise der Maintainer. Von OpenAI offengelegte Befunde.

Eine CVE-Nummer kennzeichnet eine offengelegte Schwachstelle. Die Zwei-Faktor-Authentifizierung, kurz 2FA, ergänzt das Passwort um eine zweite Anmeldeprüfung.

Der erste Sicherheitshinweis nennt Korrekturen in 0.13.4 und 0.14.0+dev, der zweite in 0.14.0. Das sind die ersten korrigierten Versionen aus historischen Hinweisen, keine Empfehlung, heute eine alte Version einzusetzen. Vor dem Upgrade die aktuell unterstützte Version des Projekts prüfen. Gogs-Sicherheitshinweis zu Wiederherstellungscodes, Gogs-Sicherheitshinweis zu Uploads.

Für die Dokumentation genügt ein knapper Eintrag: eingesetzte Revision, erreichbarer Einstiegspunkt, Belege, verantwortliche Person, Maßnahme und der Test zur Bestätigung der Korrektur. Ein Befund kann als relevant anerkannt, mit konkreter Begründung verworfen oder für weitere Untersuchungen offengehalten werden. Als behoben gilt er erst, wenn das veränderte Verhalten überprüft wurde.

Für eigene Scans gilt dieselbe Sorgfalt. Die gespeicherten CLI-Berichte dokumentieren Befunde und Prüfabdeckung. Taucht ein früherer Befund in einem späteren Scan nicht mehr auf, beweist das keine Behebung. Auch die Rückmeldung zu einem Fehlalarm unterdrückt diese Schwachstellenklasse nicht dauerhaft. Befundhistorie und Rückmeldungen.

Automatische Sicherheitsprüfungen für Pull Requests aktivieren

Nach der ersten Repository-Prüfung folgt die Prüfung von Pull Requests als nächste Ebene. In Codex settings das Repository auswählen. Unter Review security vulnerabilities die Option Auto security review aktivieren und All PRs wählen. Für eine schrittweise Einführung mit freiwilliger Teilnahme lassen sich stattdessen persönliche Einstellungen verwenden.

On PR open startet eine erste Prüfung beim Öffnen des Pull Requests, On every push wiederholt sie bei neuen Codeänderungen. Whenever code review runs koppelt die Sicherheitsprüfung an das allgemeine Code Review. Ein bereits vorhandener Security-Cloud-Scan ist optional. Dessen Bedrohungsmodell lässt sich wiederverwenden; alternativ kann der Pfad zu einer Bedrohungsmodelldatei im Repository angegeben werden. Security Review einrichten.

Automatische Prüfungen melden standardmäßig Befunde der Stufen Hoch und Kritisch. Manuell angeforderte Prüfungen schließen standardmäßig auch die Stufe Mittel ein. Die Schwellenwerte lassen sich unabhängig voneinander ändern. Eine manuelle Prüfung wird mit dem PR-Kommentar @codex security review angefordert. Den vollständigen Nachweis enthält der Security Report der zugehörigen Aufgabe. Auf GitHub veröffentlichte Befunde übernehmen die Sichtbarkeit des Pull Requests.

Dies ist eine gezielte Sicherheitsprüfung. Das allgemeine Code Review kann ebenfalls Sicherheitsprobleme melden, daher sind Überschneidungen zu erwarten. Die umfassendere Codex-Review-Anleitung hilft dabei, die beiden Prüfungen passend einzusetzen.

Codex Security CLI für lokale Scans und Pre-Commit einrichten

Die CLI ermöglicht dieselbe Art der Repository-Untersuchung in einem skriptfähigen Werkzeug. Der Quellcode steht unter Apache 2.0, das öffentliche npm-Paket heißt @openai/codex-security. Öffentlicher Quellcode bedeutet keinen uneingeschränkten Zugang zu Scans. Offizieller Quellcode und Lizenz, Voraussetzungen für die CLI.

Der in Cloud enthaltene Zugang zum Modell Daybreak Blue bleibt auf Cloud beschränkt. Er gewährt keinen Zugang zu diesem Modell über andere Security-Produkte oder die API. Vor der Verlagerung eines Scans in CI daher den vorgesehenen Anmeldeweg und den Modellzugang prüfen. Grenzen des Produktzugangs.

Bei den Veröffentlichungsdaten ist genau zu unterscheiden: Das GitHub-Repository wurde am 13. Juli 2026 angelegt. Seine aktuell öffentliche Historie beginnt mit einem Initialisierungs-Commit vom 15. Juli, die npm-Veröffentlichungen beginnen am 28. Juli. Der 13. Juli allein belegt also nicht, dass die lizenzierte npm-CLI an diesem Tag ausgeliefert wurde. Für eine reproduzierbare Einrichtung die Paketversion festschreiben. Repository-Metadaten, erster Commit, npm-Veröffentlichungshistorie.

Erforderlich sind Node.js 22.13.0 oder neuer innerhalb der 22er-Reihe, Node 24 oder Node 26 sowie Python 3.10 oder neuer. Im Repository anmelden und die Ausgabedateien außerhalb des Checkouts speichern:

npx @openai/codex-security@0.1.31 login
npx @openai/codex-security@0.1.31 scan . --auth chatgpt \
  --output-dir ../codex-security-results --dry-run
npx @openai/codex-security@0.1.31 scan . --auth chatgpt \
  --output-dir ../codex-security-results

report.md, findings.json und coverage.json prüfen. Die Abdeckung kann vollständig, teilweise oder unbekannt sein. Auch ohne gemeldete Befunde sind zurückgestellte Bereiche und offene Fragen zu lesen. Die Befehle folgen dem CLI-Schnellstart.

Die Pre-Commit-Prüfung wird mit npx @openai/codex-security@0.1.31 install-hook installiert. Sie scannt Änderungen im Staging-Bereich und außerhalb davon, blockiert standardmäßig Befunde der Stufe Hoch sowie Scan-Fehler und erhält ein vorhandenes Pre-Commit-Skript. Da beide Arten von Änderungen einbezogen werden, sollten unabhängige Experimente für die Auswertung nicht in der Arbeitskopie liegen. Verhalten des Hooks.

Die oben genannte Paketversion und die Befehle wurden während der Vorbereitung dieses Artikels geprüft. Ergebnisse eines authentifizierten lokalen Scans, gemessene Scan-Dauern oder ermittelte Scan-Kosten werden hier nicht angegeben.

Die CLI in CI einbinden und SARIF aufbewahren

SARIF ist ein standardisiertes Dateiformat für Sicherheitsbefunde. Damit kann ein anderes Werkzeug jedes Problem an der zugehörigen Stelle im Quellcode anzeigen. Der Export der Datei und der Kauf eines gehosteten Dashboards sind getrennte Entscheidungen.

Ein CI-Secret namens CODEX_SECURITY_API_KEY für ein Konto oder eine API-Organisation mit dem erforderlichen Scan-Zugang anlegen. Der Schlüssel authentifiziert den Runner ohne interaktive Anmeldung über ChatGPT. Das folgende GitHub-Actions-Beispiel scannt vertrauenswürdige PRs aus demselben Repository, vergleicht exakt die Basis- und die PR-Revision, exportiert SARIF und bewahrt die Ergebnisse auf. Es basiert auf der offiziellen CI-Vorlage, schreibt die für diesen Artikel geprüfte Paketversion fest und blockiert zunächst ab Schweregrad Hoch. Für eine Einführung, die nur Hinweise liefert, --fail-on-severity high entfernen. Scan-Fehler und unvollständige Prüfabdeckung müssen trotzdem beachtet werden.

Als .github/workflows/codex-security.yml speichern:

name: Codex Security
on:
  pull_request:
jobs:
  security:
    if: github.event.pull_request.head.repo.full_name == github.repository && github.actor != 'dependabot[bot]'
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020
        with:
          node-version: '26'
      - uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97
        with:
          python-version: '3.14'
      - name: Install trusted CLI outside the checkout
        run: npm install --prefix "$RUNNER_TEMP/security-cli" --ignore-scripts --no-audit --no-fund @openai/codex-security@0.1.31
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1
        with:
          ref: ${{ github.event.pull_request.head.sha }}
          fetch-depth: 0
          persist-credentials: false
      - name: Scan and export
        env:
          OPENAI_API_KEY: ${{ secrets.CODEX_SECURITY_API_KEY }}
          CODEX_SECURITY_STATE_DIR: ${{ runner.temp }}/security-state
          BASE_SHA: ${{ github.event.pull_request.base.sha }}
          HEAD_SHA: ${{ github.event.pull_request.head.sha }}
        run: |
          set -euo pipefail
          cli="$RUNNER_TEMP/security-cli/node_modules/.bin/codex-security"
          out="$RUNNER_TEMP/security-results"
          base="$(git merge-base "$BASE_SHA" "$HEAD_SHA")"
          scan_exit=0
          "$cli" scan . --diff "$base" --head "$HEAD_SHA" \
            --auth api-key --output-dir "$out" \
            --fail-on-severity high --json \
            > "$RUNNER_TEMP/security-result.json" || scan_exit=$?
          if test -f "$out/scan-manifest.json"; then
            "$cli" export "$out" --export-format sarif \
              --source-root "$GITHUB_WORKSPACE" \
              --output "$out/results.sarif"
          fi
          exit "$scan_exit"
      - name: Keep reports, including SARIF when available
        if: always()
        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a
        with:
          name: codex-security-results
          path: |
            ${{ runner.temp }}/security-results
            ${{ runner.temp }}/security-result.json
          retention-days: 7

Der Workflow erhält den Exit-Code des Scans und exportiert zugleich die verfügbaren versiegelten Ergebnisse. Exit-Code 0 bedeutet, dass der gewählte Prüfbereich vollständig abgedeckt wurde und die festgelegten Schweregradregeln erfüllt. Exit-Code 1 bedeutet, dass ein Befund den Schwellenwert erreicht. Exit-Code 2 steht für einen Fehler oder unvollständige Abdeckung, einschließlich teilweiser oder unbekannter Abdeckung. Ein grüner Scan, der nur Hinweise liefert, bleibt ein Bericht über den gewählten Prüfbereich und ist kein Sicherheitszertifikat. Artefaktexporte und Exit-Codes.

Um SARIF als GitHub-Code-Scanning-Meldungen anzuzeigen, den Schritt upload-sarif und die zugehörigen Berechtigungen aus der offiziellen Vorlage ergänzen. Öffentliche Repositories werden unterstützt; für private und interne Repositories muss GitHub Code Security aktiviert sein. Mit SARIF als Artefakt wie im obigen Beispiel lassen sich die Ergebnisse prüfen, ohne ein kostenloses Dashboard für private Repositories zu versprechen. Voraussetzungen für SARIF in GitHub.

Für GitLab eignet sich die CI/CD-Vorlage von OpenAI für den Produktiveinsatz. Sie deckt Merge-Request-Diffs, Scans des geschützten Standardbranches und optional aktivierte geplante Scans ab. Die native SARIF-Übernahme erfordert GitLab Ultimate 19.2 oder neuer. Gewöhnliche Berichtsartefakte sind ein separater Weg, wenn die Berechtigung für dieses Dashboard fehlt.

CI-Läufe nutzen die Berechtigungen des Runners und können dessen Umgebung übernehmen. Sachfremde Zugangsdaten gehören nicht in den Job; Codeänderungen sollten aus vertrauenswürdigen Quellen stammen. Sobald ein Budget feststeht, einen Wert für --max-cost ergänzen. Das ist eine geschätzte Obergrenze, die durch bereits laufende Anfragen überschritten werden kann. CI-Voraussetzungen, Kostenkontrolle.

Fünf sinnvolle Einsätze, nach Nutzen geordnet

1. Ein SaaS-Team ändert Anmeldung oder Mandantenzugriff. Zuerst den Ausgangszustand scannen, das Bedrohungsmodell verbessern und Security Review für die PRs aktivieren. Der Nutzen: eine bessere Chance, Fehler bei der Trennung von Konten zu erkennen, bevor Kunden damit konfrontiert werden. Die für die Authentifizierung verantwortliche Person bleibt an der Prüfung beteiligt.
2. Ein Gründer übernimmt eine ältere Anwendung. Das Repository einmal scannen und die anerkannten Befunde zuweisen, bevor neue Features hinzukommen. So kann aus einem unbekannten Rückstand eine kurze Liste belegter Aufgaben werden, statt eines pauschalen Auftrags zur Neuentwicklung.
3. Ein GitLab-Team hat keinen verwalteten Sicherheitsscanner. CLI-Prüfungen auf Merge-Request-Diffs ausführen und SARIF sowie Prüfabdeckung als Artefakte sichern. Der Nutzen ist eine wiederholbare Prüfdokumentation im bereits betriebenen CI-System.
4. Eine Agentur betreut mehrere Kunden-Repositories. Die fortsetzbaren Sammelscans der CLI verwenden und Architekturkontext sowie Befundhistorie für jeden Kunden getrennt halten. Das kann wiederholte Einrichtungsschritte reduzieren und die Übergabe der Wartung präziser machen. Sammelscans.
5. Ein Team hat viele ungeklärte Sicherheitsmeldungen im Backlog. Mit dem Workflow zur Backlog-Triage von Codex Security die Scanner-Ergebnisse anhand des aktuellen Codes und der vorhandenen Schutzmaßnahmen prüfen. Der Nutzen sind Belege dafür, welche Tickets Entwicklungszeit verdienen. Die bisherigen Scanner weiterlaufen lassen. Backlog-Triage.

Zwei mögliche Dienstleistungen rund um Codex Security

Die aussichtsreichste Möglichkeit ist eine betreute Einführung von Sicherheitsprüfungen für kleine Teams. Ein Gründer bezahlt für Einrichtung, Bedrohungsmodell, CI-Integration und regelmäßige menschliche Bewertung der Befunde – statt für eine weitere Oberfläche über einem Scan-Knopf.

Die Google-Schätzungen von DataForSEO für die USA ergaben in diesem Durchlauf 720 monatliche Suchanfragen für „software vulnerability scanning“ und 90 für „code security scanner“. Suchanfragen sind keine zahlenden Kunden; der breitere Begriff umfasst zudem Tätigkeiten außerhalb von Repository-Scans. Der Semgrep-Code-Preis von $150 im Monat für fünf Mitwirkende liefert einen konkreten Vergleichswert für eine klar begrenzte Dienstleistung. Semgrep als Preisvergleich.

Die kleinste verkaufbare Fassung könnte ein kundeneigenes Repository, ein dokumentiertes Bedrohungsmodell, den CI-Workflow und eine geprüfte Liste von Befunden umfassen. Der Zugang sollte über den Kunden laufen, die Nutzungskosten sollten sichtbar bleiben. Die Schwierigkeit liegt im Betrieb: Es braucht genügend Kenntnis der Anwendung, um irreführende Befunde zurückzuweisen und sensible Korrekturen zu prüfen. Eine verkaufte Sicherheitsgarantie würde über die Beweislage hinausgehen.

Eine zweite Möglichkeit sind Prüfnachweise für Releases von Agenturen. Eine Agentur könnte für jede Kundenübergabe einen datierten Nachweis über den Prüfbereich, anerkannte Befunde, verbleibende Lücken und verifizierte Korrekturen anbieten. Die breite Suchanfrage „vulnerability scanning tools“ erreicht geschätzt 1,900 monatliche Suchanfragen in den USA. Sie misst allerdings das Interesse an Werkzeugen aus mehreren Sicherheitsbereichen. Das stützt eine Hypothese für Kundengespräche, belegt aber keine Nachfrage nach genau diesem Produkt.

Das MVP könnte gespeicherte Scan-Artefakte und freigegebene Bewertungen in einem kompakten Kundenbericht zusammenführen. Dabei kommt es auf Übertragbarkeit und Vertrauen an: SARIF lässt sich weitergeben, doch der geschäftliche Wert entsteht durch eine ehrliche Einordnung, einschließlich unvollständiger Prüfabdeckung. Ein automatisch erzeugter Bericht allein ist leicht kopierbar. Sämtliche Suchzahlen sind monatliche Keyword-Schätzungen von DataForSEO, abgerufen am 30. September 2026. Keine davon belegt einen wachsenden Markt oder eine Kaufabsicht.

Welche Prüfungen weiterhin nötig sind

Abhängigkeitsscans bleiben erforderlich: Sie prüfen die Pakete und Versionen, die eine Anwendung einbindet. Dasselbe gilt für Secret-Scans, die offengelegte Zugangsdaten erkennen. Die Analyse eines Repositories kann ein damit zusammenhängendes Problem untersuchen, ersetzt aber weder das vollständige Paketverzeichnis noch die Überwachung von Zugangsdaten.

Deterministische SAST-Prüfungen bleiben sinnvoll, wenn ihre breite, wiederholbare Abdeckung oder die eigenen Nachweisanforderungen wichtig sind. OpenAI erklärt ausdrücklich, dass Codex Security SAST ergänzt. Der Agent lässt sich ohne den Kauf einer kostenpflichtigen Suite ausprobieren; die bestehende Prüfabdeckung wird dadurch nicht überflüssig. Cloud-FAQ.

Bei Autorisierungscode bleibt die menschliche Prüfung erforderlich. Authentifizierung klärt die Identität; Autorisierung bestimmt, auf welche Kundendaten oder Aktionen diese Identität zugreifen darf. Die Regeln hängen von geschäftlichen Vorgaben und Annahmen zum Betrieb ab, die ein Scanner missverstehen kann. Die verantwortliche Person sollte Mandantengrenzen, Administratorrechte, Wiederherstellungsabläufe und Regressionstests prüfen. Das ist eine technische Empfehlung, die mit der vom Anbieter genannten Notwendigkeit menschlicher Bedrohungsbewertung übereinstimmt.

Auch die Scan-Umgebung muss begrenzt bleiben. Cloud verwendet isolierte Container; lokale und CI-Scans nutzen die jeweils lokalen Berechtigungen. Die Anleitung zur Sandbox-Sicherheit behandelt die separate Aufgabe, den Zugriff eines Agenten zu begrenzen.

Codex oder die Sicherheitsprüfung von Claude Code?

Wenn unmittelbar eine Sicherheitsprüfung ausstehender Änderungen gebraucht wird und das Team bereits Claude Code nutzt, bietet sich dieses Werkzeug weiterhin an. Lokal /security-review ausführen oder die Security-Review-GitHub-Action von Anthropic für PR-Kommentare und die Filterung von Fehlalarmen konfigurieren. Diese Funktionen stehen Nutzern von Claude Code zur Verfügung, einschließlich kostenpflichtiger Pro-/Max- und API-Console-Konten. Claude-Sicherheitsprüfung einrichten.

Codex Security Cloud passt, wenn ein verwalteter Ausgangsscan des Repositories, Commit-Überwachung, geplante Scans und vorbereitete Korrekturen gefragt sind. Die CLI passt, wenn gespeicherte Befundhistorien, Artefakte zur Prüfabdeckung und SARIF-Exporte den lokalen Ablauf oder CI-Prozess ergänzen. Dieser Vergleich belegt keinen Sieger bei Genauigkeit oder Kosten.

Bei beiden Systemen sollte die Filterkonfiguration geprüft werden. Die Security-Review-Action von Anthropic dokumentiert Ausschlüsse, darunter Denial of Service und die Erschöpfung von Ressourcen. Ein Problem mit erschöpftem Speicherplatz wie beim Gogs-Upload-Fall verlangt deshalb eine gezielte Prüfung dieser Regeln. Die Action ist ein separates Angebot gegenüber dem gehosteten Code-Review-Produkt von Claude. Repository der Security-Review-Action von Anthropic.

Am Montag eine verantwortliche Person für ein Repository benennen. Den Ausgangsscan durchführen, das Bedrohungsmodell korrigieren, die ersten Befunde einordnen und zunächst eine CI-Prüfung mit Hinweisen einführen. Erst danach den Schweregrad festlegen, ab dem die Prüfung blockiert. Nutzungskosten und ungeklärte Prüfabdeckung dokumentieren, bevor ein weiteres Repository hinzukommt.

Für die Einbindung in den bestehenden Entwicklungsprozess des Teams: Ich entwickle KI-Systeme für den Produktiveinsatz.