Codex Security Cloud: 4 ChatGPT-Stufen scannen Code [2026]

OpenAI hat seinem Coding-Assistenten Codex einen Wächter zur Seite gestellt. Codex Security Cloud, vorgestellt am 29. September 2026 auf der DevDay-Konferenz in San Francisco, durchsucht angebundene GitHub-Repositories nach Schwachstellen, baut dafür ein eigenes Bedrohungsmodell und schlägt Fixes vor, ganz ohne dass ein Entwickler am Rechner sitzen muss. Für die Softwarebranche ist das mehr als nur ein weiteres Feature in einer langen Liste von DevDay-Ankündigungen. Es ist der Versuch, Sicherheitsprüfung von einer punktuellen Aufgabe zu einem dauerhaft laufenden Hintergrundprozess zu machen, der sich selbst organisiert.

Der Dienst reiht sich in ein Jahr ein, in dem GitHub Copilot, Cursor, Amazon Q Developer und GitLab Duo alle in Richtung autonomer Code-Agenten drängen. Codex Security Cloud setzt dabei einen eigenen Akzent: Statt nur Vorschläge für vorhandene Scanner-Treffer zu liefern, soll der Agent selbst Schwachstellen finden, doppelte Meldungen entfernen und Korrekturen vorbereiten, während die Rechenarbeit vollständig in der Cloud läuft.

Was ist OpenAI Codex Security Cloud?

Codex Security Cloud ist laut OpenAI ein Sicherheits-Agent innerhalb von Codex, der Quellcode liest, daraus ein codebasiertes Bedrohungsmodell ableitet und anschließend gezielt nach ausnutzbaren Schwachstellen sucht. Der Dienst verbindet sich mit GitHub-Repositories und kann wahlweise auf Abruf, nach einem Zeitplan oder automatisch nach jedem neuen Commit scannen. Gefundene Probleme werden nicht nur aufgelistet, sondern vom Agenten zusätzlich überprüft, bevor ein Fix vorgeschlagen wird.

Der entscheidende Unterschied zu klassischen Scannern liegt im Ablauf. Werkzeuge wie CodeQL oder Snyk arbeiten regelbasiert: Sie vergleichen Code mit bekannten Mustern und Schwachstellendatenbanken. Codex Security Cloud geht einen Schritt weiter und untersucht jeden Treffer im Kontext der jeweiligen Anwendung, bevor er als relevant eingestuft wird. OpenAI nennt das Finding-Investigation statt reiner Finding-Generation. Zusätzlich dedupliziert der Agent Meldungen, die auf dieselbe Ursache zurückgehen, um die Zahl der Alarme für Entwicklerteams zu reduzieren.

Teil des Angebots ist der Zugriff auf Modelle aus OpenAIs Cybersecurity-Initiative Daybreak Blue, ohne dass dafür eine separate Daybreak-Anwendung nötig wäre. Diese Modelle sind laut OpenAI speziell auf sicherheitsrelevante Aufgaben trainiert, etwa das Erkennen von Angriffsmustern in großen Codebasen. Für Leser, die sich bereits mit Copilot Autofix beschäftigt haben, dürfte das Prinzip vertraut wirken, nur dass OpenAI den Scan-Umfang auf ganze Repositories statt einzelner Codescanning-Alerts ausweitet.

Der Zeitplan: Von der ersten Vorschau bis zur Cloud-Version

Codex Security ist kein Produkt, das am 29. September aus dem Nichts erschienen ist. OpenAI hatte bereits im März 2026 eine erste Research-Preview-Version angekündigt, die für ChatGPT Pro, Business, Enterprise und Edu freigeschaltet wurde, inklusive eines kostenlosen ersten Monats. Diese frühe Version lief über Codex im Browser und war auf einzelne Projekte statt ganzer Repositories begrenzt.

Auf der DevDay 2026 folgte dann die Cloud-Erweiterung. OpenAI präsentierte sie als Teil eines Pakets von mehr als 20 Ankündigungen rund um ChatGPT, Codex und neue Modelle, darunter auch das kurz zuvor vorgestellte Codex Cloud mit GPT-6.1 Sol. Laut einem Bericht von TechCrunch vom Veranstaltungstag lässt die Cloud-Version Scans über ganze Repositories hinweg zeitgesteuert oder nach jedem Commit laufen, untersucht Treffer, dedupliziert sie und bereitet Fixes direkt im Hintergrund vor, selbst wenn der Laptop des Entwicklers geschlossen ist.

Auch der Entwickler und Blogger Simon Willison, der die Keynote in einem Live-Blog mitschrieb, notierte den Zugriff auf Daybreak Blue sowie die automatische Deduplizierung als zentrale neue Elemente. Nach seinen Aufzeichnungen betonte OpenAI zudem, Erkenntnisse aus einem internen Security-Sprint in die neue Version eingearbeitet zu haben, ohne dafür genaue Kennzahlen zu nennen.

Datum	Meilenstein	Details
März 2026	Erste Research-Preview	Codex Security für Pro, Business, Enterprise, Edu; erster Monat kostenlos; Fokus auf Einzelprojekte
29. September 2026	DevDay-Keynote in San Francisco	Vorstellung von Codex Security Cloud als Teil von über 20 Produktankündigungen
29. September 2026	Cloud-Scan-Funktion live	Scan ganzer Repositories, Zeitplan- und Commit-Trigger, Zugriff auf Daybreak Blue
Ab Ende September 2026	Token-basierte Abrechnung	Bestandskunden erhalten Vorlauf, bevor kostenpflichtige Nutzung startet
Erste Oktoberwoche 2026	Erste unabhängige Praxistests	Berichte über uneinheitliche Ergebnisse bei Schwachstellensuche, u. a. am Open-Source-Projekt curl

So funktioniert der Scan technisch

Der Ablauf eines Scans folgt laut OpenAIs Produktdokumentation einem festen Muster. Zuerst verbindet sich Codex Security Cloud mit dem gewählten GitHub-Repository und liest die Projektstruktur, Abhängigkeiten und Konfigurationsdateien ein. Daraus entsteht ein Bedrohungsmodell, das auf die konkrete Anwendung zugeschnitten ist, statt generische Checklisten abzuarbeiten. Anschließend sucht der Agent aktiv nach Schwachstellen, validiert jeden Treffer einzeln und entfernt Duplikate, bevor er einen Fix vorbereitet.

Scans lassen sich auf drei Arten auslösen: manuell auf Abruf, nach einem festen Zeitplan oder automatisch, sobald neuer Code in den Hauptzweig gelangt. Vereinfacht beschrieben, folgt die Logik hinter einem Zeitplan-Scan diesem Prinzip:

Scan-Richtlinie (vereinfachtes Prinzip, keine offizielle Syntax)
  Repository: angebundenes GitHub-Repo
  Trigger: on_demand | scheduled | on_new_commit
  Schritte:
    1. Projektstruktur und Abhaengigkeiten einlesen
    2. Bedrohungsmodell fuer die Codebasis erstellen
    3. Schwachstellen suchen
    4. Jeden Treffer einzeln validieren
    5. Duplikate zusammenfuehren
    6. Fix vorschlagen, optional Pull Request oeffnen

Nach Berichten vom DevDay-Event, etwa von Simon Willison, kann der Agent nicht nur Vorschläge auflisten, sondern bei ausreichender Berechtigung direkt einen Pull Request mit dem vorbereiteten Fix erstellen. Die eigentliche Rechenarbeit läuft dabei in der Cloud weiter, auch wenn kein Entwicklergerät mehr aktiv verbunden ist, ein Muster, das OpenAI bereits bei der breiteren Codex-Cloud-Funktion für normale Coding-Aufgaben eingeführt hatte.

Preise und Verfügbarkeit: Wer darf den Dienst nutzen?

Codex Security Cloud bleibt offiziell eine Research-Preview-Funktion. Zugang haben laut OpenAIs Hilfeseite Nutzer der Tarife ChatGPT Pro, Business, Enterprise und Edu. Für die Cloud-Version rechnet OpenAI die Nutzung tokenbasiert ab, ähnlich wie bei anderen Codex-Cloud-Funktionen. Bestandskunden werden vorab informiert und müssen der kostenpflichtigen Nutzung aktiv zustimmen, bevor Scans über das Freikontingent hinaus abgerechnet werden. Ist kein Guthaben hinterlegt, pausiert der Dienst die Scans automatisch, statt unbegrenzt weiterzulaufen.

Eine einfache Preisliste pro Repository oder pro Sitz hat OpenAI bisher nicht veröffentlicht. Das deckt sich mit der allgemeinen Linie von OpenAI bei Codex: Auch die kurz zuvor gestartete Funktion Codex Cloud mit GPT-6.1 Sol wurde tokenbasiert statt mit festen Monatspreisen abgerechnet. Für IT-Abteilungen in Österreich bedeutet das in der Praxis, dass die tatsächlichen Kosten stark vom Umfang und der Scan-Frequenz des jeweiligen Repositories abhängen und sich erst nach einigen Wochen im Testbetrieb realistisch einschätzen lassen.

Codex Security Cloud im Vergleich zur Konkurrenz

OpenAI tritt mit Codex Security Cloud in ein Feld, das längst nicht leer ist. GitHub bietet mit Copilot Autofix seit 2024 eine Funktion, die Vorschläge für von CodeQL gemeldete Schwachstellen liefert. Der Unterschied zu Codex Security Cloud liegt im Ausgangspunkt: Copilot Autofix setzt auf bereits vorhandene CodeQL-Alerts auf und schlägt dafür Korrekturen vor, während Codex Security Cloud selbst aktiv nach neuen Schwachstellen sucht, statt nur auf bestehende Scanner-Treffer zu reagieren.

Snyk, seit Jahren als spezialisierte AppSec-Plattform etabliert, deckt mit statischer Analyse, Abhängigkeitsprüfung, Container- und Infrastructure-as-Code-Scans ein deutlich breiteres technisches Spektrum ab. GitLab Duo wiederum ist tief in die GitLab-eigenen Merge-Request- und Pipeline-Workflows eingebettet und bietet damit Vorteile für Teams, die bereits vollständig auf GitLab setzen. Amazon Q Developer punktet vor allem dort, wo Code, Infrastruktur und Deployment ohnehin in der AWS-Welt liegen.

Tool	Anbieter	Kernprinzip	Scan-Auslöser	Fix-Vorschläge
Codex Security Cloud	OpenAI	Agent sucht aktiv nach Schwachstellen, baut eigenes Bedrohungsmodell	Auf Abruf, Zeitplan, neuer Commit	Ja, inklusive automatischer PR-Erstellung
Copilot Autofix	GitHub (Microsoft)	Vorschläge für bestehende CodeQL-Alerts	Nach CodeQL-Scan-Lauf	Ja, als Vorschlag im Pull Request
Snyk	Snyk Ltd.	Statische Analyse, Abhängigkeits- und Container-Scans	CI/CD-Integration, manuell	Ja, automatisierte Fix-PRs für bekannte Issues
GitLab Duo	GitLab Inc.	KI-Unterstützung im GitLab-Sicherheits- und Merge-Request-Workflow	Pipeline-gebunden	Erklärung, Priorisierung, teilweise Fixes
Amazon Q Developer	AWS	Code- und Abhängigkeitsanalyse mit AWS-Integration	IDE- und CI-Integration	Ja, Vorschläge in unterstützten Workflows

Wichtig für die Einordnung: Keine der verfügbaren Quellen liefert einen kontrollierten Benchmark, der Codex Security Cloud direkt gegen diese Werkzeuge testet. Der Vergleich beruht auf den jeweiligen Produktbeschreibungen der Anbieter, nicht auf einer unabhängigen Prüfung unter gleichen Bedingungen. Wer also eine Entscheidung zwischen diesen Tools treffen muss, sollte die Angaben als Ausgangspunkt für einen eigenen Pilotversuch nehmen, nicht als abschließendes Urteil.

Der curl-Vorfall: Ein erster Praxistest sorgt für Diskussion

Wenige Tage nach dem Start kursierte in der Entwickler-Community ein Praxisbericht über einen informellen Test am Open-Source-Projekt curl, dessen Maintainer Daniel Stenberg bekannt für seine kritische Haltung gegenüber KI-Sicherheitswerkzeugen ist. Laut diesem Bericht fanden Codex Security und ein weiteres KI-Werkzeug zunächst keine Probleme im curl-Code, während ein drittes Tool später sechs CVE-würdige Schwachstellen meldete.

Dieser Fall ist kein kontrollierter Benchmark und sollte nicht als Beweis für die Genauigkeit eines einzelnen Produkts gelesen werden. Er zeigt aber ein grundsätzliches Problem der aktuellen Generation von KI-Sicherheitsagenten: Unterschiedliche Werkzeuge kommen bei derselben Codebasis zu unterschiedlichen Ergebnissen, und es fehlt bislang an unabhängigen, wiederholbaren Tests, die Präzision und Trefferquote vergleichbar machen. Für Unternehmen, die sich auf ein einzelnes Werkzeug verlassen wollen, ist das ein Warnsignal, keine Entwarnung.

Kritikpunkte: Prompt Injection, Fehlalarme und Zugriffsrechte

Ein Agent, der Quellcode, Issues, Konfigurationsdateien und Dokumentation liest, um daraus automatisch Schlüsse zu ziehen, bringt ein spezifisches Risiko mit: Eingebettete Anweisungen in Repository-Inhalten könnten versuchen, den Agenten zu manipulieren, etwa um Daten abzugreifen oder unsichere Änderungen auszulösen. Dieses Muster ist als Prompt Injection bekannt und betrifft nicht nur Codex Security Cloud, sondern alle agentenbasierten Coding-Werkzeuge, die eigenständig Code lesen und verändern dürfen. Wie stark Codex Security Cloud gegen diese Angriffsklasse abgesichert ist, lässt sich aus den bisher veröffentlichten Unterlagen nicht abschließend beurteilen.

Dazu kommen klassische Fragen der Zugriffskontrolle. Sobald ein Dienst vollen Lesezugriff auf ein Repository erhält, entstehen Fragen zu Berechtigungsstufen, Aufbewahrungsfristen für gescannten Code, Mandantentrennung bei Enterprise-Kunden und zur Nachvollziehbarkeit automatisch generierter Pull Requests. OpenAI hat diese Punkte in den verfügbaren Unterlagen bisher nicht im Detail beantwortet. Wer bereits mit Vorfällen wie GhostApproval oder der Shai-Hulud-Kampagne gegen KI-Coding-Assistenten zu tun hatte, weiß, wie schnell aus einem hilfreichen Agenten ein Angriffsvektor werden kann, wenn Berechtigungen zu großzügig vergeben werden.

Auch die automatische Deduplizierung von Funden ist zweischneidig. Sie reduziert die Zahl der Alarme und macht den Dienst im Alltag praktikabler, kann aber auch unterschiedliche Angriffspfade fälschlich zusammenfassen und damit die Nachvollziehbarkeit einzelner Schwachstellen erschweren. Ohne unabhängige Prüfung der Dedupe-Logik bleibt offen, wie oft das in der Praxis tatsächlich passiert.

Historischer Kontext: Vom CodeQL-Alert zum autonomen Agenten

Um die Tragweite von Codex Security Cloud einzuordnen, hilft ein Blick zurück. GitHub stellte Copilot Autofix für CodeQL-Alerts bereits im März 2024 vor und positionierte es als Funktion, die automatisch Fixvorschläge für bereits erkannte Schwachstellen liefert. Dieses Modell blieb bis heute die dominante Vorlage für KI-gestützte Sicherheitswerkzeuge: Ein deterministischer Scanner findet das Problem, eine KI schlägt die Lösung vor.

Codex Security Cloud bricht mit dieser Reihenfolge. Statt auf einen vorgeschalteten Scanner zu warten, übernimmt der Agent selbst die Rolle der Fundstellen-Suche, bewertet jeden Treffer im Kontext der Anwendung und bereitet parallel die Korrektur vor. Belastbare, eigenständige Zahlen zur Verbreitung von Copilot Autofix hat GitHub bisher nicht gesondert veröffentlicht, da das Unternehmen in der Regel breitere Kennzahlen zu Copilot insgesamt oder zur GitHub Advanced Security Suite nennt. Diese Verschiebung von reiner Alert-Bearbeitung zu eigenständiger Bedrohungsanalyse ist der eigentliche Bruch in der Entwicklung, nicht allein das Datum des DevDay-Launches.

Marktauswirkungen: Was bedeutet das für etablierte AppSec-Anbieter?

Für spezialisierte Sicherheitsanbieter wie Snyk entsteht durch Codex Security Cloud zunächst kein direkter Ersatzdruck. Die verfügbaren Quellen stellen klar, dass OpenAIs Agent keine vollständige Abdeckung von Paket-Schwachstellendatenbanken, Container-Scans oder Compliance-Reporting bietet, wie sie etablierte AppSec-Plattformen liefern. Der Agent ergänzt diese Werkzeuge eher, als sie zu ersetzen.

Für GitHub selbst ist die Lage komplizierter. Microsoft betreibt mit Copilot Autofix bereits ein ähnliches Angebot innerhalb desselben Ökosystems, auf das Codex Security Cloud direkt zugreift, schließlich scannt der OpenAI-Dienst GitHub-Repositories. Damit positioniert sich OpenAI als Schicht oberhalb der GitHub-eigenen Sicherheitsfunktionen, was für Unternehmen zu einer Entscheidung zwischen zwei sich teilweise überlappenden Werkzeugen im selben Workflow führen kann. Entwicklerteams, die ohnehin schon OpenAIs Agents API und Codex-Plattform nutzen, dürften das als logische Erweiterung ihres bestehenden Werkzeugkastens sehen, während reine GitHub-Copilot-Kunden erst abwägen müssen, ob sich eine zweite, tokenbasierte Sicherheitslösung lohnt.

Langfristig dürfte der eigentliche Wettbewerbsdruck nicht von Codex Security Cloud selbst ausgehen, sondern von der Erwartungshaltung, die der Dienst bei Kunden erzeugt. Sobald ein großer Anbieter autonome, zeitgesteuerte Sicherheitsscans als Standardfunktion anbietet, steigt der Druck auf Wettbewerber, ähnliche Automatisierung nachzuziehen, unabhängig davon, wie ausgereift die jeweilige Umsetzung tatsächlich ist.

Reaktionen aus der Entwickler-Community

In Foren und auf Plattformen wie X und im OpenAI-Community-Forum mischte sich in den ersten Tagen nach dem Launch Neugier mit Skepsis. Viele Entwickler begrüßten grundsätzlich den Gedanken eines Agenten, der eigenständig nach Schwachstellen sucht, statt nur auf bestehende Scanner-Ergebnisse zu reagieren. Zugleich tauchten in denselben Diskussionen wiederholt Fragen auf, die sich auch in den offiziellen Unterlagen nicht restlos klären lassen: Wie transparent dokumentiert der Agent, warum er einen Treffer als relevant oder irrelevant einstuft, und wie lässt sich im Nachhinein nachvollziehen, welche Fundstellen durch die Deduplizierung zusammengefasst wurden.

Ein wiederkehrendes Thema in diesen frühen Reaktionen war der Vergleich mit der ersten Version von Copilot Autofix, die GitHub 2024 einführte und die zunächst ebenfalls mit Skepsis aufgenommen wurde, bevor sie sich im Alltag vieler Teams etablierte. Diese Parallele deutet darauf hin, dass die Akzeptanz solcher Werkzeuge weniger von der ersten Produktvorstellung abhängt als davon, wie verlässlich sie sich über mehrere Monate im produktiven Einsatz schlagen. Belastbare, repräsentative Umfragedaten zur Stimmung unter Codex-Security-Nutzern liegen für diesen frühen Zeitpunkt noch nicht vor.

Lektionen aus früheren Sicherheitsvorfällen bei KI-Coding-Agenten

Codex Security Cloud erscheint nicht in einem Vakuum. 2026 war bereits von mehreren Vorfällen geprägt, bei denen Schwächen in KI-gestützten Entwicklerwerkzeugen selbst zum Sicherheitsproblem wurden. Die Schwachstellensammlung Plugin4Shell betraf mehrere KI-Coding-Agenten gleichzeitig, von denen ein Teil auch Monate nach Bekanntwerden noch ungepatcht blieb. Die GitSpawn-Lücken zeigten ein ähnliches Muster bei einer anderen Gruppe von Agenten.

Diese Vorfälle sind deshalb relevant für die Einordnung von Codex Security Cloud, weil sie belegen, dass die Werkzeuge, die Schwachstellen in fremdem Code finden sollen, selbst zur Angriffsfläche werden können. Ein Dienst, der volle Leserechte auf Repositories erhält und eigenständig Pull Requests erstellen darf, muss nach denselben Maßstäben geprüft werden wie jede andere privilegierte Software-Lieferkette. Unternehmen, die Codex Security Cloud einführen, sollten diese Lehre in ihre eigene Risikobewertung einfließen lassen, statt den Dienst allein aufgrund der Herkunft von OpenAI als von Haus aus sicher zu behandeln.

Prognosen: Wohin sich KI-Sicherheitsagenten entwickeln

• Unabhängige Benchmarks für KI-Sicherheitsagenten werden 2027 zu einem eigenen Marktsegment, da Vorfälle wie der curl-Test den Bedarf an vergleichbaren Testverfahren offengelegt haben.
• GitHub dürfte Copilot Autofix in den kommenden Monaten um repository-weite, zeitgesteuerte Scans erweitern, um mit Codex Security Cloud funktional gleichzuziehen.
• Die Preismodelle für KI-Sicherheitsscans werden sich von reiner Tokenabrechnung hin zu hybriden Modellen mit Mindestpauschalen verschieben, sobald Unternehmen mit großen Repositories die tatsächlichen Kosten kennen.
• Prompt-Injection-Schutz für Coding-Agenten wird zum eigenständigen Prüfpunkt in Sicherheitsaudits, ähnlich wie es heute bereits für klassische Webanwendungen gilt.
• Etablierte AppSec-Anbieter wie Snyk und GitLab dürften eigene, aktiv suchende Agenten-Funktionen ergänzen, statt sich auf reine Scanner-plus-Fixvorschlag-Modelle zu beschränken.

Diese Einschätzungen beruhen auf der aktuellen Marktdynamik rund um KI-Coding-Werkzeuge und den bekannten Reaktionsmustern der beteiligten Anbieter, nicht auf offiziellen Ankündigungen der genannten Unternehmen.

Was Entwicklerteams in Österreich jetzt beachten sollten

Für österreichische Unternehmen, die GitHub-Repositories mit sensiblen Daten betreiben, lohnt sich vor einem produktiven Einsatz von Codex Security Cloud ein genauer Blick auf drei Punkte. Erstens die Datenresidenz: Da der Scan vollständig in der Cloud läuft, sollte vorab geklärt werden, wo Code während der Analyse verarbeitet wird und wie lange er dort verbleibt, gerade im Hinblick auf die DSGVO. Zweitens die Berechtigungsvergabe: Repository-Zugriffe sollten so eng wie möglich gefasst werden, um das Risiko bei einer möglichen Kompromittierung des Dienstes selbst zu begrenzen.

Drittens die Kostenkontrolle: Da die Abrechnung tokenbasiert erfolgt, sollten IT-Verantwortliche vor einem Rollout auf mehrere Repositories ein Testbudget für einige Wochen festlegen und die tatsächlichen Scan-Kosten beobachten, bevor sie den Dienst unternehmensweit ausrollen. Gerade bei großen, aktiven Repositories mit vielen täglichen Commits kann die Zahl der ausgelösten Scans schnell steigen.

Häufig gestellte Fragen zu Codex Security Cloud

Ist Codex Security Cloud bereits allgemein verfügbar?
Nein. Der Dienst läuft weiterhin als Research Preview und steht Nutzern der ChatGPT-Tarife Pro, Business, Enterprise und Edu zur Verfügung. Umfang, Preise und Funktionen können sich während der Preview-Phase noch ändern.

Was kostet die Nutzung von Codex Security Cloud?
OpenAI rechnet die Cloud-Scans tokenbasiert ab. Eine feste Preisliste pro Repository oder Nutzer gibt es nicht. Bestandskunden müssen der kostenpflichtigen Nutzung aktiv zustimmen, bevor Scans über ein Freikontingent hinaus abgerechnet werden.

Wie unterscheidet sich Codex Security Cloud von GitHub Copilot Autofix?
Copilot Autofix schlägt Korrekturen für bereits von CodeQL gemeldete Schwachstellen vor. Codex Security Cloud sucht selbst aktiv nach Schwachstellen in der gesamten Codebasis, validiert jeden Treffer und bereitet danach eigenständig einen Fix vor.

Kann Codex Security Cloud Snyk oder GitLab Duo ersetzen?
Nach aktuellem Stand nicht vollständig. Dem Dienst fehlt die Tiefe spezialisierter Plattformen bei Container-Scans, Abhängigkeitsdatenbanken und Compliance-Reporting. Er eignet sich eher als Ergänzung zu bestehenden AppSec-Werkzeugen.

Welche Repositories kann der Dienst scannen?
Codex Security Cloud verbindet sich mit angebundenen GitHub-Repositories. Genaue Angaben zu unterstützten Programmiersprachen, Paket-Ökosystemen oder Repository-Größen hat OpenAI in den bisher veröffentlichten Unterlagen nicht im Detail genannt.

Öffnet der Agent automatisch Pull Requests?
Laut Berichten von der DevDay-Keynote kann der Agent bei entsprechender Berechtigung eigenständig Pull Requests mit vorbereiteten Fixes erstellen. Die endgültige Freigabe und Prüfung bleibt dabei weiterhin Aufgabe des Entwicklerteams.

Welche Risiken bestehen bei der Nutzung?
Zu den wichtigsten Risiken zählen Prompt-Injection-Angriffe über manipulierte Repository-Inhalte, zu weit gefasste Zugriffsrechte und mögliche Fehleinschätzungen bei der automatischen Deduplizierung von Funden. Unabhängige Prüfungen dazu liegen bislang nur begrenzt vor.

Gibt es bereits unabhängige Tests zur Treffergenauigkeit?
Nur vereinzelte, nicht kontrollierte Praxistests, etwa am Open-Source-Projekt curl, bei dem verschiedene KI-Sicherheitswerkzeuge zu unterschiedlichen Ergebnissen kamen. Belastbare, unabhängige Benchmarks stehen noch aus.