C’è un momento, in quasi ogni team di sicurezza, in cui il lavoro smette di sembrare un esercizio tecnico e diventa un problema economico. Non accade quando emerge una vulnerabilità critica. Accade prima, quando il team viene sommerso da segnalazioni che sembrano plausibili, ma richiedono ore di lettura, verifica e contestualizzazione prima di capire se siano davvero pericolose. È dentro questa frizione quotidiana che va letto il messaggio di OpenAI su Codex Security: il bersaglio non è il SAST in sé, ma l’idea che la sicurezza del codice possa partire solo da una lista statica di rilievi.
La precisazione è importante, perché il dibattito si presta facilmente a una lettura caricaturale. OpenAI non sta dicendo che il SAST sia inutile, né che l’analisi statica debba sparire dalle pipeline. Sta dicendo qualcosa di più sottile: se l’obiettivo è trovare vulnerabilità complesse, ridurre il costo del triage e proporre correzioni più credibili, allora ancorare l’intero processo a un report SAST può diventare un limite.
Il punto, in altre parole, non è soltanto individuare un flusso sospetto tra input e punto sensibile del codice, ma capire se il comportamento del sistema rispetti davvero l’invariante di sicurezza che il software sembra voler garantire.
Indice degli argomenti:
Che cos’è il SAST e perché il tema emerge ora
Vale la pena chiarire il termine che OpenAI mette al centro della sua tesi. SAST significa static application security testing: è l’analisi del codice senza eseguire l’applicazione, condotta per individuare pattern di rischio, flussi di dati sospetti, uso improprio di API sensibili e violazioni di regole di secure coding.
È diventato uno dei pilastri del DevSecOps perché porta feedback molto presto nel ciclo di sviluppo e si integra bene nelle pipeline CI/CD, dove conta avere controlli ampi, ripetibili e automatizzabili.
Il tema nasce adesso perché il contesto sta cambiando. Le codebase moderne sono più stratificate, dipendono da framework, librerie e catene di trasformazione che rendono meno immediato capire se un controllo logico continui a valere dopo parsing, normalizzazione e decoding. Allo stesso tempo i team di sicurezza soffrono il costo del triage: ricevere molti alert non basta, se poi manca il contesto per distinguere rapidamente ciò che è davvero sfruttabile.
Con l’arrivo di agenti capaci di leggere repository, generare test e validare ipotesi, il mercato alza l’asticella e chiede non solo segnalazioni, ma prove. È in questa tensione, più che in una semplice disputa terminologica, che va collocato il blog di OpenAI.
SAST: cosa sta dicendo OpenAI
Per capire la portata di questa posizione bisogna osservare come OpenAI sta presentando Codex Security. Il prodotto, annunciato in anteprima sperimentale il 6 marzo 2026, viene descritto come un agente di sicurezza applicativa che costruisce contesto sul repository, genera un modello di minaccia specifico, cerca vulnerabilità, prova a validarle in un ambiente isolato e, quando riesce, propone anche una patch coerente con l’intento del sistema.
Pochi giorni dopo, il 16 marzo, OpenAI ha pubblicato il post “Why Codex Security Doesn’t Include a SAST Report” per chiarire la scelta di non far partire l’agente da un report statico preesistente.
Nella documentazione ufficiale la società ribadisce due aspetti decisivi. Il primo è che Codex Security nasce per validare i segnali prima di interrompere un umano, allegando quando possibile evidenze di riproduzione, log e passaggi di verifica.
Il secondo è che il prodotto non sostituisce né il SAST né la revisione manuale: li affianca con ragionamento semantico e auto-validazione. Questo punto conta molto, perché ridimensiona ogni interpretazione ideologica. OpenAI non sta proclamando la fine degli strumenti statici; sta provando a ridefinire dove questi strumenti si fermano e dove comincia il lavoro di un agente orientato al comportamento.
Perché il SAST da solo non basta più
La tesi di OpenAI ruota attorno a un’osservazione semplice: molte vulnerabilità rilevanti non nascono dal fatto che un input non filtrato arrivi a una funzione sensibile, ma dal fatto che un controllo apparentemente corretto non garantisca davvero la proprietà di sicurezza su cui il sistema fa affidamento. È il passaggio dalla logica del semplice flusso di dati alla logica degli invarianti.
Il punto è meno astratto di quanto sembri. Un sistema può validare un URL con una regex, decodificarlo in un secondo momento e poi usarlo in un redirect. In quel flusso il controllo esiste. Ma la domanda che conta non è se il controllo sia stato chiamato: è se continui a valere dopo decoding, parsing, normalizzazione e interpretazione da parte del framework.
Non è una sfumatura accademica. È esattamente il genere di catena in cui emergono bypass, ambiguità di parsing, errori di ordine delle operazioni e differenze tra l’intento del programmatore e il comportamento reale del software.
Il riferimento di OpenAI a CVE-2024-29041 in Express serve proprio a questo. In quel caso il problema non era l’assenza di una allowlist, ma il fatto che URL malformati potessero aggirare implementazioni comuni di allowlist a causa di come i target di redirect venivano codificati e poi interpretati. Il flusso dei dati era chiaro. La parte difficile era stabilire se la validazione continuasse a vincolare il dato dopo la trasformazione successiva.
Perché la tesi di OpenAI ha un fondamento
Su questo terreno la posizione di OpenAI è difficile da liquidare. OWASP ricorda da tempo che i tool di analisi del codice hanno limiti strutturali: coprono bene alcune classi di difetti, ma sono meno efficaci su problemi di autenticazione, controllo accessi, configurazione e, più in generale, su tutto ciò che non si lascia descrivere bene come semplice flusso di dati.
Anche il Code Review Guide della stessa OWASP osserva che l’ideale di uno strumento capace di trovare automaticamente le falle con pochi falsi positivi è ancora lontano dallo stato dell’arte, e che questi strumenti funzionano spesso come ausilio all’analista più che come sostituto del suo ragionamento.
È qui che Codex Security prova a cambiare prospettiva. Nel post OpenAI spiega che, quando incontra un passaggio che somiglia a una validazione o a una sanitizzazione, l’agente non lo tratta come una casella da spuntare. Cerca di capire quale garanzia il codice stia cercando di offrire e poi prova a falsificarla. In pratica significa leggere il percorso di codice con il contesto completo del repository, isolare le porzioni minime testabili, usare micro-fuzzing o anche strumenti formali quando servono, ed eseguire ipotesi in sandbox per distinguere tra “potrebbe essere un problema” e “questo è un problema”.
Questa impostazione ha anche un valore manageriale, non solo tecnico. OpenAI sembra aver compreso che il costo maggiore nella sicurezza del software non sta più semplicemente nello scoprire possibili bug, ma nel gestire la massa di segnali deboli generati dagli strumenti.
In molte organizzazioni il collo di bottiglia non è non vedere abbastanza, ma vedere troppo e con una priorità insufficiente. Letta così, la scelta di partire dal repository e non da un report SAST è anche una scelta economica: ridurre il lavoro di triage prima che il problema arrivi sul tavolo del team.
Dove la posizione resta discutibile
Sarebbe però un errore trasformare questa intuizione in una smentita definitiva del SAST. La prima ragione è operativa: gli strumenti statici restano il modo più rapido, ripetibile e deterministico per applicare controlli diffusi su vasta scala. La stessa FAQ di Codex Security afferma che il prodotto completa il SAST e che gli strumenti esistenti continuano a offrire una copertura ampia e deterministica. Questa frase vale più di molte letture polarizzate del blog. Se anche OpenAI riconosce quel ruolo, allora il punto non è sostituzione contro continuità, ma distribuzione intelligente dei compiti.
La seconda ragione riguarda la scalabilità. Il SAST è nato per essere industriale: gira presto, gira spesso e può essere applicato in modo sistematico su grandi volumi di codice, anche accettando semplificazioni. Un agente che legge, ragiona, costruisce modelli di minaccia, tenta validazioni e produce prove tende inevitabilmente a essere più costoso. Non a caso la documentazione di Codex Security indica che le scansioni iniziali possono richiedere da diverse ore a più giorni sui repository più grandi.
Questo non invalida il modello, ma chiarisce dove sta il compromesso: più profondità e meno rumore, sì, ma non allo stesso costo operativo dei controlli statici tradizionali.
La terza ragione è epistemologica. OpenAI critica giustamente il bias che un report SAST può introdurre quando diventa la mappa iniziale dell’indagine. Ma un agente basato su modelli introduce a sua volta altri bias: quelli del training, delle euristiche inferenziali, della qualità del modello di minaccia generato e dell’ambiente di validazione disponibile.
Se il rischio del SAST è fissarsi troppo su ciò che è codificato nelle regole, il rischio di un agente è costruire narrazioni causali persuasive ma non sempre complete. L’auto-validazione alza molto l’asticella, ma non elimina il tema della fiducia: lo sposta dal motore di regole al sistema che decide dove guardare, come formulare l’ipotesi e quando considerarla sufficientemente confermata.
C’è infine una questione di governance. Un tool statico tradizionale, per quanto imperfetto, è più facile da collocare in policy, checklist, audit trail e processi regolati: regole note, output standard, integrazioni mature. Un agente che genera modelli di minaccia, esegue validazioni adattive e propone patch è potenzialmente più potente, ma anche più difficile da incasellare nei processi di controllo.
Per molte imprese la domanda, quindi, non è solo “funziona meglio?”, ma anche “come lo si governa, come lo si misura, come lo si rende verificabile nel tempo?”.
Una valutazione a tutto tondo
La lettura più equilibrata a mio avviso è questa: OpenAI ha ragione nel criticare l’idea che la sicurezza del codice possa esaurirsi nella logica del semplice flusso di dati. Ha ragione anche nel sostenere che molte vulnerabilità decisive sono problemi di semantica, stato e invarianti, e che per affrontarle serva un’analisi più vicina a quella di un security researcher che a quella di un mero classificatore di pattern.
Ma non avrebbe senso convertire questa intuizione in una tesi assoluta contro il SAST, perché il SAST continua a fare bene ciò per cui è nato: standardizzare, coprire, automatizzare e mettere in sicurezza la base.
La vera novità, semmai, è un’altra. Con Codex Security OpenAI sta cercando di ridefinire il valore della sicurezza applicativa nell’era degli agenti AI. Non più solo vedere più cose, ma vedere meglio quelle che meritano attenzione. Non più soltanto segnalare, ma dimostrare. Non più produrre liste di sospetti, ma avvicinarsi a un output che abbia già il formato operativo di una decisione: questo è reale, questo è il contesto, questa è la prova, questa è la correzione più coerente.
Il SAST non è morto
Se questa impostazione manterrà le promesse, non assisteremo alla fine del SAST, ma alla sua ricollocazione all’interno del processo. Gli strumenti statici presidieranno la copertura continua e i controlli ripetibili; i sistemi agentici prenderanno in carico i casi ambigui, costosi e ad alta intensità di contesto. In mezzo resterà l’elemento decisivo: il giudizio umano. Non perché manchino gli strumenti, ma perché nelle vulnerabilità più serie il problema non è mai soltanto trovare una riga di codice sbagliata.
È capire quale proprietà del sistema si riteneva protetta, quando ha smesso di esserlo e quale correzione ripristina davvero quell’equilibrio.
Takeaway finali
- Il blog di OpenAI non dichiara morto il SAST: contesta il SAST come punto di partenza obbligato per un agente che deve scoprire e validare vulnerabilità complesse.
- Il punto forte della tesi è lo spostamento dal controllo del flusso al controllo degli invarianti: non basta che esista una validazione, bisogna capire se regga dopo parsing, decoding e trasformazioni.
- Il punto debole è operativo: più ragionamento e più validazione significano tempi, costi e problemi di governance superiori rispetto ai controlli statici tradizionali.
- Lo scenario più realistico è ibrido: SAST per copertura e disciplina di base, agenti AI per analisi semantica, prioritizzazione e conferma delle vulnerabilità ad alto impatto.
