OpenAI sier de bevisst har valgt å ikke bygge Codex Security rundt tradisjonelle SAST-rapporter (Static Application Security Testing). I stedet starter systemet med selve kodebasen, arkitektur og antatte tillitsgrenser, før det forsøker å validere funn med mer konkret evidens.
Poenget deres er at mange alvorlige sårbarheter ikke bare handler om «user input går til farlig sink», men om hvorvidt sikkerhetskontroller faktisk fungerer etter transformasjoner i koden. Med andre ord: forskjellen mellom at en sjekk finnes, og at den faktisk beskytter.
Fra mønstergjenkjenning til verifisering
I innlegget beskriver OpenAI en arbeidsmåte der agenten prøver å:
- forstå kontekst i hele repoet
- isolere små, testbare kodebiter
- teste antakelser gjennom validering i sandbox
- løfte fram funn med høyere bevisgrad før mennesker må triagere
Dette er et tydelig signal i retning av «færre, men mer bekreftede» funn. For sikkerhetsteam som ofte drukner i støy fra store skann, er dette en relevant prioritering.
Hva betyr dette for utviklere og AppSec-team?
OpenAI argumenterer ikke for at SAST er ubrukelig. Tvert imot beskrives SAST som nyttig for kjente mønstre, policy-håndheving og bred dekning. Hovedpoenget er at en agent som skal finne komplekse feil i praksis ikke bør låses til en ferdig funnliste fra start.
Denne diskusjonen treffer en kjent utfordring i moderne app-sikkerhet: mange feil ligger i sekvenser av normalisering, parserlogikk og validering, ikke i én åpenbar «rød linje» fra input til sink. NVD-beskrivelsen av CVE-2024-29041 (Express open redirect) brukes som eksempel på akkurat dette mønsteret.
Hvorfor saken er viktig nå
Med økende bruk av agentiske verktøy i utvikling, blir spørsmålet ikke bare om verktøy finner flere sårbarheter, men om de finner de riktige og kan dokumentere hvorfor de er reelle. OpenAIs linje peker mot en mer forskerlik metode i sikkerhetsarbeid: hypoteser, testing og reproduksjon.
For 1t-lesere er dette særlig relevant fordi det kan påvirke hvordan neste generasjon sikkerhetsverktøy integreres i CI/CD-pipeliner: mindre volumfokus, mer kvalitet på funn.