Codex Security i centrum dowodzenia agentami

Codex Security to agent bezpieczeństwa aplikacji od OpenAI, który pomaga zespołom wyszukiwać, potwierdzać i naprawiać podatności; @codex security review zleca przegląd pull requestu pod kątem bezpieczeństwa, a codex agents (/agents) nadzoruje sesje naprawcze. Znalezisko jest zamknięte dopiero wtedy, gdy nieprzechodzący test exploita przechodzi po poprawce, a nazwany właściciel ją zatwierdza.

Ta strona jest dla developerów, którzy przygotowują poprawki, tech leadów odpowiedzialnych za proces review i CTO, którzy po incydencie muszą odpowiedzieć na pytanie „kto to sprawdził?”. Scenariusz jest znajomy: w poniedziałek przegląd bezpieczeństwa zgłasza 23 problemy, trzech inżynierów uruchamia po sesji Codex, żeby naprawić „te ważne”, a w czwartek nikt nie wie, które znaleziska były prawdziwe, które poprawki weszły do main i która sesja wciąż czeka na zatwierdzenie. Poniższy proces daje każdemu znalezisku jedną ścieżkę od zgłoszenia do scalonej, przetestowanej poprawki i pokazuje wszystkie pracujące nad nim sesje na jednym ekranie.

Co daje proces przeglądu bezpieczeństwa w Codex

• Mapę czterech narzędzi bezpieczeństwa w Codex: co każde raportuje i co może zablokować.
• Sekcję bezpieczeństwa w AGENTS.md, która steruje @codex security review i jest w kontekście lokalnych przeglądów.
• Tabelę minimalnych uprawnień: tylko odczyt do skanowania, worktree do poprawek, nigdy pełny dostęp.
• Skryptowy przegląd, który zapisuje znaleziska jako JSON i kończy się błędem przy potwierdzonych problemach krytycznych lub wysokich.
• Regułę triażu, która zamienia znalezisko w test kończący się niepowodzeniem, zanim powstanie jakakolwiek poprawka.
• Rutynę nadzoru nad agentami naprawczymi w centrum dowodzenia, w tym codex queue do sterowania nimi bez otwierania każdej sesji.

Które narzędzie bezpieczeństwa w Codex do czego służy?

Praca nad bezpieczeństwem w Codex odbywa się w czterech miejscach. Różnią się tym, kto je uruchamia, co widzą i czy mogą zatrzymać merge.

Narzędzie	Gdzie działa	Kto uruchamia	Co raportuje	Czy może zablokować merge?
Codex Security	Agent bezpieczeństwa aplikacji od OpenAI, konfigurowany według przewodnika Codex Security od OpenAI	Zwykle zespół bezpieczeństwa aplikacji	Podatności do znalezienia, potwierdzenia i naprawy, według opisu samego OpenAI	Nie według dokumentacji OpenAI (sprawdzonej 2026-08-28); kieruj jego znaleziska do swojej kolejki triażu
@codex security review	Pull requesty w GitHubie	Autor lub recenzent pull requestu	Komentarze przeglądu skupione na bezpieczeństwie	Tylko jeśli reguły merge wymagają rozwiązania komentarzy
codex review / codex exec review (--base, --uncommitted, --commit)	Twoja maszyna lub runner	Autor albo skrypt	Znaleziska w diffie, niezacommitowanych zmianach lub commicie. W wersji 0.157.1 te tryby nie przyjmują promptu, więc instrukcje bezpieczeństwa docierają do nich tylko przez AGENTS.md, który lokalne sesje wczytują jako instrukcje projektu; zasianym znaleziskiem sprawdź, czy przegląd je stosuje. Własny prompt działa tylko bez flagi trybu.	Tak, gdy hook albo krok CI sprawdza wynik
Centrum dowodzenia agentami (codex agents, /agents)	Twój terminal, połączony z lokalnym demonem app-server	Ty	Stan każdej sesji: działa, zablokowana, czeka na dane	Nie. To miejsce, w którym nadzorujesz sesje naprawiające znaleziska

Co ta strona mogła zweryfikować i kiedy

Dokumentacja Codex od OpenAI opisuje Codex Security jako „an application security agent that helps security and engineering teams find, confirm, and fix vulnerabilities”, a przewodnik po integracji z GitHubem omawia @codex security review, automatyczne przeglądy i własne reguły review w AGENTS.md. Oba źródła sprawdziliśmy ostatnio 2026-08-28. Dostępności w planach, ekranów konfiguracji i harmonogramu skanów ta strona nie podaje; sprawdź je w swoim workspace ChatGPT przed wdrożeniem. Wszystko o centrum dowodzenia, codex review, codex exec i codex queue zweryfikowaliśmy w Codex CLI 0.157.1 dnia 2026-09-26.

Kolejność kroków poniżej jest ważniejsza niż wybór narzędzia. Tanie, prywatne kontrole idą pierwsze, więc przegląd pull requestu widzi mniej defektów, a każde znalezisko, z dowolnego narzędzia, trafia do tej samej kolejki triażu.

Przeprowadź każde znalezisko bezpieczeństwa przez jeden proces review

1. Podłącz repozytorium. Włącz code review w Codex dla repozytorium zgodnie z opisem w podłączeniu Codex do GitHuba. To samo połączenie obsługuje @codex security review.

2. Zapisz reguły bezpieczeństwa raz. Dodaj reguły bezpieczeństwa do sekcji ## Review guidelines w AGENTS.md (szablon poniżej). Przeglądy pull requestów korzystają z tej sekcji. Lokalne sesje Codex wczytują AGENTS.md jako instrukcje projektu, więc reguły są w kontekście także dla codex review; OpenAI opisuje tę sekcję tylko dla przeglądów na GitHubie, więc sprawdź, czy lokalny przegląd ją stosuje, testem na zasianych podatnościach opisanym niżej w sekcji „Skąd wiesz, że Codex Security wyłapuje to, co ważne?”.

3. Wyznacz właściciela bezpieczeństwa dla każdej ryzykownej ścieżki. Wpisz go do CODEOWNERS dla src/auth/, src/billing/ i wszystkiego, co dotyka sekretów. GitHub prosi wtedy tę osobę o review każdego pull requestu, który dotyka tych ścieżek, więc znaleziska Codex trafiają do właściciela, a nie tylko do autora.

4. Uruchom lokalny przegląd, zanim powstanie pull request. Użyj skryptowego przeglądu z następnej sekcji, żeby autorzy naprawili oczywiste problemy, zanim ktokolwiek inny je zobaczy.

5. Wywołuj @codex security review na ryzykownych pull requestach. Dodaj ten komentarz do każdego pull requestu, który dotyka uwierzytelniania, parsowania danych wejściowych, dostępu do plików lub sekretów. Zostań przy przeglądach na żądanie, dopóki reguły nie są dostrojone, a potem rozważ automatyczne przeglądy opisane w code review z Codex.

6. Włącz Codex Security według przewodnika OpenAI, gdy powyższy proces już działa, i kieruj jego znaleziska do tej samej kolejki triażu. Tam sprawdź dostępność w twoim planie i ekrany konfiguracji; ta strona ich nie podaje.

Oto sekcja bezpieczeństwa do AGENTS.md, którą recenzent sprawdzi na podstawie samego diffu. Podmień ścieżki na swoje, zachowaj kształt reguł. Reguły zostają po angielsku, tak jak prompty.

## Review guidelines

### Security
- P0: a route under src/api/ that reads an ID from the request and loads a record
  without calling requireOwnership() or requireRole(). Missing authorization.
- P0: SQL built with template strings or + concatenation anywhere under src/db/.
  Only the query builder or parameterised queries are allowed.
- P0: a secret, token or private key literal in any file. Secrets come from env only.
- P1: a new dependency in package.json that is not on the internal allowlist in
  docs/security/allowed-deps.md. Check the name exists on the registry.
- P1: user-controlled URLs passed to fetch() without the allowlist in src/net/egress.ts.
- Do not flag: test fixtures under tests/fixtures/, which contain fake credentials
  on purpose.
- When you report a finding, name the rule above that it violates.

Reguła o zależnościach ma konkretny powód. Pozycja LLM04 Supply Chain w OWASP GenAI LLM Top 10 2026 (GenAI Security Project, publikacja 2026-08-04, odczyt 2026-09-26) ostrzega, że asystenci kodowania wymyślają wiarygodnie brzmiące nazwy pakietów, które atakujący potem rejestrują; OWASP nazywa to „slopsquatting”.

Uruchom skryptowy przegląd bezpieczeństwa ze strukturalnymi znaleziskami

Na komentarzu z przeglądu trudno oprzeć bramkę. Na pliku JSON łatwo. codex exec przyjmuje plik --output-schema i zapisuje ostatnią wiadomość pod ścieżką podaną w -o, więc przegląd może przerwać krok przy potwierdzonych znaleziskach o wysokiej wadze.

Zapisz schemat jako security-findings.schema.json:

{
  "type": "object",
  "additionalProperties": false,
  "required": ["findings"],
  "properties": {
    "findings": {
      "type": "array",
      "items": {
        "type": "object",
        "additionalProperties": false,
        "required": ["id", "severity", "status", "file", "line", "cwe", "summary", "evidence", "reproduction"],
        "properties": {
          "id": { "type": "string" },
          "severity": { "type": "string", "enum": ["critical", "high", "medium", "low"] },
          "status": { "type": "string", "enum": ["confirmed", "suspected"] },
          "file": { "type": "string" },
          "line": { "type": "integer" },
          "cwe": { "type": "string" },
          "summary": { "type": "string" },
          "evidence": { "type": "string" },
          "reproduction": { "type": "string" }
        }
      }
    }
  }
}

Następnie uruchom przegląd w terminalu z katalogu głównego repozytorium. Flaga zatwierdzania stoi przed exec, bo codex exec w wersji 0.157.1 nie ma własnego -a:

# Remove the previous run's output so a failed run cannot pass on stale data
rm -f findings.json

codex -a never exec -c 'default_permissions=":read-only"' \
  --output-schema security-findings.schema.json \
  -o findings.json \
  "Security sweep of the changes on this branch against origin/main. Apply the
   Security rules in AGENTS.md. Mark a finding confirmed only if you can point to
   the exact input that reaches the vulnerable line; otherwise mark it suspected.
   Put that input in reproduction. Do not edit files."

# Fail on confirmed critical or high findings
jq -e '[.findings[] | select(.status == "confirmed"
        and (.severity == "critical" or .severity == "high"))] | length == 0' findings.json

Linia rm -f ma znaczenie: jeśli codex exec się nie powiedzie (logowanie, sieć, przekroczony czas), nowy findings.json nie powstanie, a bez tej linii jq przeszedłby na pliku z poprzedniego uruchomienia, czyli dałby cichy zielony wynik. Gdy pliku nie ma, jq kończy się błędem.

Wbudowany profil uprawnień :read-only sprawia, że przegląd nie może zmienić kodu, który ocenia. -a never sprawia, że nigdy nie zatrzymuje się z pytaniem: polecenie wymagające szerszego dostępu kończy się błędem, zamiast czekać na człowieka, którego nie ma. Profile uprawnień to mechanizm preferowany przez OpenAI, wciąż w wersji beta; jeśli zespół zostaje przy starszej fladze, użyj zamiast niego --sandbox read-only, nigdy obu naraz. OpenAI pisze, że oba systemy „do not compose”. W naszym teście z Codex 0.157.1 (2026-09-26) podanie obu nie dało błędu: codex exec działał z wartością --sandbox, a profil uprawnień został zignorowany (dla --sandbox workspace-write z :read-only nagłówek startowy pokazał sandbox: workspace-write), więc mieszana konfiguracja nie robi tego, na co wygląda. Zanim zaufasz przeglądowi, sprawdź linię sandbox: w nagłówku, który codex exec wypisuje przy starcie. Ten sam przegląd w CI ustaw według strony Codex w CI/CD: nigdy nie uruchamiaj go na niezaufanym refie, gdy w środowisku są sekrety.

Prompt do skopiowania: przegląd bezpieczeństwa jednego ryzykownego modułu

Audit src/auth/ and every route in src/api/ that imports from it. Look for missing
authorization checks, session fixation, token comparison without constant-time
compare, password reset flows that reveal whether an account exists, and error
responses that leak stack traces. For each finding give: file and line, the CWE,
the exact request that reaches the vulnerable code, and severity. Mark it
"confirmed" only if you traced that request through the code; otherwise "suspected".
Do not edit any file.

Zdecyduj, czego może dotykać każda sesja bezpieczeństwa

Skanowanie i naprawianie wymagają innych uprawnień. Daj każdemu zadaniu tylko tyle, ile potrzebuje, a zapisy agenta naprawczego niech trafiają do worktree, nie do głównego checkoutu.

Zadanie	Uprawnienia w Codex CLI 0.157.1	Dlaczego
Skan lub przegląd	-c 'default_permissions=":read-only"' (starszy sposób: --sandbox read-only), -a never w skryptach	Skaner nie może zmieniać tego, co ocenia
Potwierdzenie znaleziska	-c 'default_permissions=":workspace"' (starszy sposób: --sandbox workspace-write) w --worktree, domyślne zatwierdzanie on-request	Pisze jeden test kończący się niepowodzeniem, nic więcej
Propozycja poprawki	Jak przy potwierdzeniu albo, zamiast profilu, --approve-for-me, które kieruje prośby o zgodę do automatycznego przeglądu w sandboksie workspace-write	Zmiany zostają w odizolowanym checkoucie aż do pull requestu
Audyt niezaufanego repozytorium	Wybierz Open restricted w oknie „Trust this folder?”	Konfiguracja, hooki i polityki exec z niezaufanych folderów pozostają wyłączone
Cokolwiek	Nigdy --dangerously-bypass-approvals-and-sandbox poza jednorazowym sandboksem z ograniczoną siecią	Pełny dostęp pozwala agentowi edytować dowolny plik i łączyć się z siecią bez pytania

Dwa komunikaty w Codex 0.157.1 warto znać, zanim zespół bezpieczeństwa zacznie pracę. Gdy rozmowa zbierze kilka flag ryzyka cyberbezpieczeństwa, Codex ostrzega, że „extra safety checks are on”, i odpowiedzi zwalniają; odsyła przy tym do programu OpenAI Trusted Access for Cyber dla autoryzowanych prac bezpieczeństwa. Z kolei okno włączania pełnego dostępu ostrzega dodatkowo, że modele cyber „carry a higher risk of dangerous actions”. Żaden z tych komunikatów nie jest powodem, by poluzować sandbox; oba są powodem, by testy ofensywne prowadzić w jednorazowym środowisku.

Zamień każde znalezisko w test, zanim powstanie poprawka

Znalezisko z Codex Security albo z przeglądu bezpieczeństwa to twierdzenie. Faktem staje się wtedy, gdy odtworzy je test. Reguła dla zespołu: żadnej poprawki bez testu, który kończy się niepowodzeniem i demonstruje exploit, i żadnego merge, dopóki ten test nie przejdzie.

Stan znaleziska	Następny krok	Kto decyduje
Zgłoszone, waga krytyczna lub wysoka	Sesja potwierdzająca w ciągu jednego dnia roboczego	Właściciel bezpieczeństwa danej ścieżki
Zgłoszone, waga średnia lub niska	Raz w tygodniu, zbiorczo; potwierdź albo zamknij jako szum	Tech lead
Nieodtworzone po jednej sesji potwierdzającej	Zamknij jako „nie odtworzono” i zapisz dlaczego	Właściciel bezpieczeństwa
Potwierdzone (test kończący się niepowodzeniem istnieje)	Sesja naprawcza w worktree	Autor lub dyżurny developer
Pull request z poprawką przechodzi wszystkie kontrole, w tym test exploita	Merge po zatwierdzeniu	Właściciel bezpieczeństwa, nie autor poprawki
Ten sam wzorzec dwa razy okazał się szumem	Dopisz linię „Do not flag” do AGENTS.md	Tech lead

Terminy traktuj jako punkt wyjścia do dostosowania, a nie standard. Nie dostosowuj natomiast rozdziału ról: osoba zatwierdzająca poprawkę to nie ta osoba ani nie ta sesja agenta, która ją napisała.

Prompt do skopiowania: potwierdź znalezisko testem

Finding SEC-142: "GET /api/invoices/:id returns another tenant's invoice when the
ID is guessed" (src/api/invoices.ts, around line 58).

Confirm or refute it. Write one integration test in tests/security/ that logs in as
tenant A, requests an invoice ID belonging to tenant B, and asserts a 404. Run it.
If it fails, the finding is confirmed: stop and report the test name and output.
If it passes, the finding is not reproduced: explain which check blocks the request
and quote the line. Do not change any file outside tests/security/.

Prompt do skopiowania: najmniejsza poprawka potwierdzonego znaleziska

tests/security/invoice-tenant-isolation.test.ts fails and demonstrates finding
SEC-142. Make it pass with the smallest change to src/api/invoices.ts, using the
existing requireOwnership() helper. Do not modify the test. Run the full test suite
and the type check, and report both results. List every file you changed. If the
fix needs changes outside src/api/, stop and explain why instead of making them.

Nadzoruj agentów naprawczych w centrum dowodzenia

Gdy równolegle działają trzy albo cztery sesje potwierdzające i naprawcze, przełączanie terminali przestaje wystarczać. Centrum dowodzenia agentami pokazuje w jednym widoku każdą sesję na współdzielonym lokalnym demonie app-server. Otwórz je z terminala poleceniem codex agents albo z wnętrza sesji przez /agents.

1. Każdą poprawkę zaczynaj we własnym worktree i nazwij ją od znaleziska. Uruchom codex --worktree, a potem zmień nazwę sesji przez /rename na sec-142, albo naciśnij New w centrum dowodzenia. Po nazwie odnajdziesz sesję, a codex queue przyjmuje dokładną nazwę sesji.

2. Patrz na kolumnę stanu, nie na transkrypty. W wersji 0.157.1 sesja ma stan Running, Ready, Blocked albo Needs input. Komunikaty wymagające uwagi mówią, co jest nie tak: „Waiting for approval.”, „Waiting for your response.” albo „Task encountered an error.”

3. Używaj Filter, Search i Group, żeby oddzielić sesje bezpieczeństwa od prac nad funkcjami. Prefiks sec- w nazwie sprawia, że łatwo je znaleźć wyszukiwaniem.

4. Steruj bez przełączania. Wyślij instrukcję do działającej sesji z dowolnego terminala:

   codex queue --thread sec-142 --message "Also add the same ownership check to PATCH /api/invoices/:id"

5. Po merge archiwizuj, usuwaj rzadko. Archive zatrzymuje trwającą pracę zadania i jego agentów podrzędnych, a ich historię można przywrócić z listy wznawiania, czego potrzebuje dokumentacja incydentu. Delete trwale usuwa tę historię i nie da się tego cofnąć, więc zostaw je dla sesji, które nie dotykały żadnego znaleziska.

Żeby nadzorować sesje na innej maszynie, na przykład na serwerze buildów, który prowadzi długie poprawki, skieruj centrum dowodzenia na tamten app server: codex agents --remote wss://HOST:PORT --remote-auth-token-env CODEX_REMOTE_TOKEN, a -C DIR ustawia katalog roboczy dla nowych zadań. HOST, PORT i DIR podajesz swoje; token zostaje w nazwanej zmiennej środowiskowej, nigdy w linii poleceń. Przepływy wieloagentowe w Codex opisują dzielenie większej pracy na sesje.

Skąd wiesz, że Codex Security wyłapuje to, co ważne?

Cichy przegląd bezpieczeństwa sam w sobie niczego nie dowodzi. Sprawdź recenzenta, zanim mu zaufasz, i sprawdzaj każdą poprawkę bez czytania każdej linii.

• Test na zasianych podatnościach. Raz na kwartał otwórz jednorazową gałąź z pięcioma podłożonymi defektami zgodnymi z regułami w AGENTS.md: brak sprawdzenia własności, SQL sklejany ze stringów, zaszyty token, zależność spoza listy, niesprawdzany URL wychodzący. Uruchom skryptowy przegląd, @codex security review oraz, gdy jest włączony, skan Codex Security tej gałęzi i zapisz, ile wyłapało każde z nich. Ten wynik to twoja linia bazowa; spadek po zmianie reguł to regresja.
• Test exploita dla każdej poprawki. Test w tests/security/, który najpierw nie przechodzi, a potem przechodzi, dowodzi, że poprawka działa. Zostaje w zestawie testów, więc błąd nie wróci po cichu.
• Zwykłe bramki nadal działają. Typy, lint i pełny zestaw testów muszą przejść na pull requeście z poprawką, jak przy każdej innej zmianie.
• Poziom szumu. Mierz tygodniowo liczbę znalezisk zamkniętych jako „nie odtworzono”. Rosnący szum oznacza zbyt szerokie reguły; spadek wykryć na zasianej gałęzi oznacza zbyt wąskie.
• Zatwierdzenie przez człowieka. Właściciel bezpieczeństwa zatwierdza każdy merge dla znaleziska krytycznego lub wysokiego. Przegląd Codex to dane wejściowe do tej decyzji, a nie zatwierdzenie.

Co może pójść nie tak z Codex Security i centrum dowodzenia?

Pierwszy skan zasypuje zespół. Przychodzą dziesiątki znalezisk o średniej wadze i nikt żadnego nie przegląda ani nie klasyfikuje. Co zrobić: przez dwa tygodnie przeglądaj tylko krytyczne i wysokie, a każdy powtarzający się fałszywy alarm zamieniaj w linię „Do not flag”, zanim przeczytasz resztę.

Agent naprawczy sam poszerza zakres. Miał naprawić jedną trasę, a refaktoryzuje moduł uwierzytelniania. Co zrobić: w każdym prompcie naprawczym trzymaj „do not change files outside…”, odrzuć pull request i zacznij sesję od nowa od testu kończącego się niepowodzeniem.

Znaleziska są potwierdzane argumentem, a nie testem. Sesja pisze przekonujące wyjaśnienie i żadnego testu. Co zrobić: odeślij ją poleceniem codex queue --thread sec-142 --message "Write the failing test first; no explanation without it".

Niezaufane repozytorium uruchamia własne hooki. Oznaczenie repozytorium dostawcy jako zaufanego, żeby je zaudytować, włącza jego konfigurację, hooki i polityki exec. Co zrobić: niezaufany kod otwieraj przez Open restricted. Sesja, która działała, gdy folder był zaufany, może zachować tamtą konfigurację, więc po zmianie zaufania zacznij nowe zadanie.

Centrum dowodzenia pokazuje nieaktualną listę. Codex zgłasza „agent list is stale; relaunch to retry”. Co zrobić: zamknij je i uruchom codex agents ponownie. Jeśli sesji nadal brakuje, uruchom codex doctor, które diagnozuje lokalną instalację, konfigurację, uwierzytelnienie i stan środowiska uruchomieniowego.

codex queue albo codex agents odmawia startu. W wersji 0.157.1 --no-daemon nie działa z żadnym z nich: kolejkowanie „must discover the shared server”, a widok agentów „requires a shared server”. Co zrobić: usuń --no-daemon; aby trafić do innego serwera, zastąp je --remote ADDR (tych dwóch też nie można łączyć).

Aktualizacja demona przerywa trwające poprawki. codex app-server daemon update „may interrupt running work”. Co zrobić: aktualizuj, gdy centrum dowodzenia nie pokazuje sesji w stanie Running, a potem wznów przerwane sesje po nazwie.

Jak to samo zadanie rozwiązują Claude Code i Cursor?

Ta strona dotyczy tylko Codex. Claude Code ma /security-review i wtyczkę Claude Security, opisane w audytach bezpieczeństwa z Claude Code, a jego odpowiednikiem centrum dowodzenia jest Agent view, opisany w Agent view w Claude Code. Funkcje przeglądu bezpieczeństwa w Cursorze opisuje strona bezpieczeństwo w Cursorze. Bramki niezależne od narzędzia, takie jak skanery sekretów i SAST, które działają bez względu na to, który agent napisał kod, opisujemy w bramkach bezpieczeństwa dla kodu pisanego przez agentów.

Dokąd dalej z pracą nad bezpieczeństwem w Codex

Skanowanie bezpieczeństwa z Codex Audyty oparte na promptach w równoległych worktree i codzienna automatyzacja bezpieczeństwa.

Code review z Codex Warstwowa bramka review, do której podłącza się @codex security review.

Worktree w Codex Odizolowane checkouty dla każdej sesji naprawczej.

Zarządzanie Codex w przedsiębiorstwie Konfiguracja administracyjna, RBAC, logi audytowe i kontrole bezpieczeństwa dla Codex na dużą skalę.