W świecie AppSec od dawna mamy paradoks. Narzędzi do wykrywania problemów nie brakuje. Brakuje czasu, żeby z ich wyników wydobyć to, co naprawdę zasługuje na uwagę. SAST, dependency scanning, reguły, custom grep, platformy do triage’u, kolejne dashboardy. A mimo to zespoły bezpieczeństwa i tak regularnie toną nie dlatego, że nic nie widzą, tylko dlatego, że widzą za dużo i zbyt często bez sensownego kontekstu.
Dlatego marcowa zapowiedź Codex Security jest ciekawa nie z powodu marketingowego „AI zrobi security”, tylko dlatego, że OpenAI próbuje przesunąć punkt ciężkości z samego wykrywania na rozumienie systemu. To subtelna różnica, ale w praktyce bardzo ważna.
Co OpenAI właściwie ogłosiło
Według oficjalnej zapowiedzi Codex Security buduje kontekst o repozytorium, generuje edytowalny model zagrożeń, szuka podatności z uwzględnieniem realnego wpływu na dany system, a tam gdzie może, próbuje dodatkowo walidować wyniki w kontrolowanym środowisku. Następnie proponuje poprawki, które mają pasować do intencji systemu i nie wywoływać regresji.
To jest sensowny kierunek. Najbardziej kosztowny alert to nie alert, którego nie było. Najbardziej kosztowny alert to taki, który wygląda poważnie, zabiera godzinę lub dwie na sprawdzenie, a na końcu okazuje się nietrafiony. OpenAI podaje, że podczas bety na tych samych repozytoriach udało się w jednym przypadku obciąć szum o 84%, ograniczyć nadmierne zawyżanie severity o ponad 90% i zmniejszyć odsetek false positive o ponad połowę. To nadal są liczby od producenta, więc trzeba je traktować trzeźwo, ale sam kierunek optymalizacji jest trafiony.
Dlaczego model zagrożeń ma tu większe znaczenie niż sam model językowy
Jeśli ta koncepcja ma zadziałać, to nie dlatego, że model „jest sprytny”, tylko dlatego, że dostaje lepszą ramę myślenia. Edytowalny threat model jest tutaj dużo ważniejszy, niż może się wydawać na pierwszy rzut oka. Bez niego agent będzie zgłaszał wszystko, co da się nazwać „podejrzanym”. Z nim może zacząć rozumieć, gdzie w danej architekturze naprawdę są granice zaufania, co jest wrażliwe, co jest wystawione, a co tylko wygląda groźnie.
To szczególnie ważne przy błędach, które słabo wychodzą w klasycznych skanerach: logiczne obejścia autoryzacji, problemy multitenantowe, nietypowe zależności między serwisami, błędy walidacji danych albo podatności, które istnieją dopiero po połączeniu kilku zachowań aplikacji. Tego nie łapie się dobrze samym pattern matchingiem. Tu właśnie „zrozumienie systemu” robi największą różnicę.
Najmocniejsza obietnica: walidacja i poprawka, nie tylko wykrycie
W praktyce wiele organizacji nie potrzebuje kolejnego źródła alertów. Potrzebuje kogoś, kto przyniesie sprawę na takim poziomie dojrzałości, żeby developer albo security engineer mógł w ciągu kilku minut powiedzieć: „tak, to realny problem, naprawiamy to tak i tak”. Jeśli Codex Security faktycznie dowozi walidację w środowisku zbliżonym do projektu i umie zaproponować łatkę zgodną z resztą systemu, to przestaje być ciekawostką. Zaczyna być narzędziem, które może wejść do codziennego flow review.
To zresztą dobrze widać także w opisie programu dla open source. OpenAI otwarcie przyznaje, że maintainerzy nie chcą lawiny spekulatywnych zgłoszeń. Chcą mniej, ale lepiej. To jest bardzo zdrowa obserwacja. W security problemem coraz rzadziej jest brak danych. Problemem jest brak zaufania do danych, które do nas wpadają.
Na co uważać
Jednocześnie nie kupowałbym bezrefleksyjnie narracji, że agent rozwiąże AppSec jednym ruchem. Nadal potrzebujemy dobrego środowiska walidacyjnego, nadal trzeba przemyśleć dostęp do repozytoriów, sekretów i uruchamiania kodu, nadal istnieje ryzyko błędnego priorytetyzowania. Do tego dochodzi klasyczne pytanie o koszt procesu i jego przewidywalność przy większej skali.
Drugie ryzyko jest bardziej miękkie: zespoły mogą zbyt szybko uznać, że skoro mają „sprytnego agenta bezpieczeństwa”, to review manualne można odchudzić. To byłby błąd. Najlepszy scenariusz to nie zastąpienie specjalisty, tylko przesunięcie jego czasu z nudnego triage’u na ocenę naprawdę istotnych przypadków i architektonicznych decyzji.
Dlaczego ten temat warto śledzić
Czy Codex Security dowiezie to poza kontrolowaną betą? To dopiero się okaże. Ale jeśli okaże się skuteczny w większych, bałaganiarskich kodobazach, z realnym kontekstem biznesowym i złożoną architekturą, to może się okazać jednym z ciekawszych ruchów w AppSec w 2026 roku. Nie dlatego, że pokazuje najwięcej alertów. Tylko dlatego, że szanuje czas ludzi, którzy muszą z tymi alertami żyć.