Il codice scritto dall'AI è sicuro? Cosa dicono gli studi

Il 29 ottobre Veracode ha pubblicato il suo rapporto d'autunno sul codice scritto dall'AI: 18 modelli, quattro linguaggi, quattro classi di vulnerabilità. I due migliori, Claude Opus 5.5 e GPT-6-Sol, producono codice sicuro nel 73% dei casi. Letto al contrario: il miglior modello sul mercato lascia una falla nota in un compito su quattro.

Otto giorni prima avevo scritto di php2shell, la falla di PHP che un'intelligenza artificiale ha reso dimostrabile in una settimana. Le due notizie insieme raccontano il paradosso di quest'anno: la stessa tecnologia scrive codice vulnerabile e trova vulnerabilità che ci sfuggivano da vent'anni.

La domanda "il codice scritto dall'AI è sicuro?" merita una risposta fatta di dati, non di opinioni. Ho messo in fila gli studi usciti dal 2023 a oggi, separando i benchmark di laboratorio dai dati raccolti sul campo, e ho guardato cosa fanno gli strumenti nuovi, a partire dalla skill di sicurezza che Cloudflare ha pubblicato in open source.

Quanto codice scritto dall'AI contiene vulnerabilità

Veracode misura la cosa dal 2025 sempre con lo stesso metodo: chiede ai modelli di completare compiti di programmazione in Python, Java, JavaScript e C#, dove per ogni compito esiste un modo sicuro e uno insicuro di scrivere il codice, e conta quante volte il risultato contiene una vulnerabilità nota. Le classi misurate sono quattro: SQL injection, crittografia debole, cross-site scripting e log injection (CWE-89, 327, 80 e 117; le CWE sono il catalogo pubblico dei tipi di debolezza del software).

I numeri di ottobre 2026: il tasso medio di codice sicuro sale dal 56% al 62%, la quota di codice vulnerabile scende dal 44% al 38%, dieci modelli su diciotto superano il 60% contro i quattro di luglio. È il primo miglioramento vero da quando la serie esiste: dal 2025 la media era rimasta ferma al 55-56%, mentre la correttezza sintattica arrivava vicino al 100%.

Il dettaglio per classe di vulnerabilità ridimensiona l'entusiasmo.

Sulle injection SQL e sulla crittografia i modelli sono bravi da tempo, e lì non c'era quasi più margine. Il miglioramento sta tutto sull'XSS, dove si partiva da un 15% di codice sicuro. La log injection (scrivere nei log dati che arrivano dall'utente senza ripulirli) è ferma al 12-13% da ogni rilevazione: sette volte su otto il modello mette nei log quello che gli arriva dalla richiesta.

Altri due dati del rapporto. Java resta il linguaggio peggiore, con il 31% di codice sicuro contro il 64% di Python. E i modelli specializzati nel codice fanno peggio di quelli generalisti, 51% contro 54%: allenare un modello a scrivere più codice non lo allena a scriverlo sicuro.

Gli altri studi dicono la stessa cosa con metodi diversi

Secure Code Warrior ha fatto generare a 16 modelli 1.760 applicazioni complete, con una metodologia sviluppata insieme alla RMIT University, e ha contato le vulnerabilità confermate: in media circa 15 per applicazione, di cui più di quattro gravi. La debolezza più frequente è la CWE-532, informazioni sensibili scritte nei log, con oltre 8.500 casi. Nessun modello è risultato il più sicuro in modo costante.

Uno studio di luglio 2026 ha confrontato ChatGPT, Copilot e Gemini sugli script di automazione, quelli che finiscono nei processi aziendali senza che nessuno li guardi. Ogni script conteneva almeno una vulnerabilità sfruttabile, e 9 delle 17 classi trovate comparivano in tutti e tre i modelli. La conclusione degli autori: il rischio dipende dal tipo di compito più che dal modello.

Una cosa salta all'occhio a chi lavora con PHP: nessuno di questi benchmark lo misura. Veracode copre quattro linguaggi, Secure Code Warrior elenca tra i suoi framework Java, Python, C# e C, e PHP non compare. Per Laravel e WordPress abbiamo solo l'analogia, e l'analogia dice che le classi di errore sono le stesse: output non ripulito nelle viste, query costruite a mano, dati della richiesta nei log.

Perché i modelli sbagliano sempre negli stessi punti

Nel primo rapporto, nel 2025, Veracode aveva descritto il meccanismo che spiega tutto il resto: ogni compito ammetteva un'implementazione sicura e una insicura, e nel 45% dei casi i modelli hanno prodotto quella insicura. Non per incapacità, visto che la sintassi è perfetta, ma perché il modello riproduce il codice più frequente nei dati di addestramento, e il codice più frequente su internet non è il più sicuro. Gli esempi nei tutorial loggano l'intera richiesta, concatenano stringhe nelle query e saltano la validazione per brevità.

La seconda causa è che le vulnerabilità del codice generato sono soprattutto omissioni. La Cloud Security Alliance, in una nota di aprile 2026 sul debito di sicurezza del vibe coding (costruire applicazioni intere descrivendole a un modello, senza leggere il codice che produce), mette in testa alle categorie il controllo degli accessi mancante, le autorizzazioni e le credenziali scritte nel codice. Un'omissione non si vede: il codice funziona, i test passano, manca solo il pezzo che dice chi può fare cosa. L'esempio che la nota riporta è una piattaforma di chat AI con un database Firebase lasciato in lettura libera: 406 milioni di record di circa 25 milioni di utenti esposti, a gennaio 2026, per una regola di accesso mai scritta.

La terza causa è l'iterazione. Uno studio accettato a IEEE ISTAS 2025 ha preso 400 campioni di codice e li ha fatti "migliorare" dal modello più volte: dopo cinque giri le vulnerabilità critiche erano aumentate del 37,6%. I prompt orientati alla sicurezza aiutano nelle prime iterazioni, poi i miglioramenti vengono compensati da falle nuove e più sottili. È il contrario di quello che succede quando un programmatore rifinisce il proprio codice.

Poi c'è un rischio che non riguarda il codice ma le dipendenze. Uno studio presentato a USENIX Security 2025 ha analizzato 576.000 campioni di codice generati da 16 modelli: circa un pacchetto suggerito su cinque non esiste, per un totale di 205.474 nomi inventati, e il 43% di quei nomi riappare identico a ogni richiesta. È abbastanza per una tecnica di attacco con un nome suo, slopsquatting: si registra il pacchetto inventato con dentro codice malevolo e si aspetta che qualcuno lanci composer require o npm install senza controllare.

Come si presenta in Laravel

Tradotte in Laravel, le tre classi che i benchmark misurano peggio sono righe come queste. Un modello le scrive volentieri, perché le ha viste migliaia di volte, e una revisione dovrebbe fermarle.

// CWE-532: l'intera richiesta nei log, password e token compresi
Log::info('Login attempt', $request->all());

// CWE-89: query costruita concatenando l'input dell'utente
$users = DB::select("SELECT * FROM users WHERE email = '" . $request->email . "'");

// CWE-80: output stampato in una vista Blade senza escape
{!! $comment->body !!}

In PHP senza framework sono le stesse tre righe con error_log e $_POST, una query concatenata su PDO e un echo senza htmlspecialchars. Nessuna delle tre fa fallire un test funzionale. Tutte e tre superano una revisione fatta di corsa.

Il problema non è solo il modello: è chi lo usa

Il primo studio serio su questo tema è del 2023 e non misura il modello, misura le persone. A Stanford, Perry, Srivastava, Kumar e Boneh hanno messo 47 programmatori davanti a cinque compiti di sicurezza, due terzi con un assistente basato su Codex e un terzo senza. Sul compito di cifratura in Python, il 43% di chi lavorava da solo ha scritto una soluzione sicura, contro il 21% di chi aveva l'assistente. Sulla query SQL in JavaScript, il codice vulnerabile a injection è passato dal 7% al 36%.

Il dato che conta di più è un altro: chi aveva l'assistente era più convinto di aver scritto codice sicuro, e chi si fidava di più dell'assistente scriveva il codice meno sicuro. È lo stesso meccanismo di cui ho parlato a proposito delle allucinazioni e di chi non verifica: la fiducia prende il posto del controllo.

Il modello del 2023 era codex-davinci-002, lontano da quelli di oggi. I dati raccolti sul campo nel 2025 e nel 2026 dicono però che il comportamento umano non è cambiato. Apiiro ha analizzato i repository di sviluppatori di aziende Fortune 50: chi usa gli assistenti produce tre o quattro volte più codice, espone chiavi e credenziali quasi il doppio delle volte e concentra più modifiche in meno pull request, che diventano più difficili da leggere.

Le segnalazioni di sicurezza nel loro campione sono cresciute di dieci volte tra dicembre 2024 e giugno 2025. Il dato va preso con cautela, perché viene da un fornitore di strumenti di sicurezza e la parte sulla velocità è stata contestata; la direzione però coincide con tutto il resto.

Infine le CVE, le falle pubbliche con un codice ufficiale. Il Vibe Security Radar della Georgia Tech ricostruisce, attraverso i commit di correzione, quante vulnerabilità pubblicate nascono da codice generato: 6 a gennaio 2026, 15 a febbraio, 35 a marzo, 74 in tutto a fine marzo. I ricercatori stimano che quelle non attribuite siano da cinque a dieci volte tanto, perché quando nel commit non resta traccia dello strumento usato la falla rimane anonima.

Da chi guida un team queste cifre si leggono così: lo strumento non ha abbassato la qualità del singolo programmatore, ha alzato il volume di codice che arriva in revisione e ha abbassato la quantità di attenzione per riga. Il collo di bottiglia si è spostato da chi scrive a chi legge, cioè alla code review.

L'AI che trova le falle: Cloudflare, Anthropic e OpenAI

Il rovescio della medaglia è l'altra metà della notizia di quest'anno. php2shell è stata dimostrata da un ricercatore con un modello in una settimana, un lavoro che prima richiedeva mesi a un team. A maggio avevo raccontato di Project Glasswing, la scelta di Anthropic di dare Claude Mythos solo a una quarantina di organizzazioni perché troppo bravo a trovare vulnerabilità. Sei mesi dopo gli stessi modelli che scrivono il 38% di codice vulnerabile sono diventati revisori di sicurezza, e non più solo per pochi.

A giugno Cloudflare ha raccontato come ha costruito il proprio sistema di ricerca delle vulnerabilità e ha pubblicato, con licenza MIT, la skill da cui è partita: security-audit, un file di istruzioni con liste di classi di attacco e piccoli validatori, che un agente di programmazione (Claude Code, Codex e simili) carica quando gli si chiede un audit. Il lavoro è diviso in sei fasi: ricognizione dell'architettura, caccia per classe di attacco con agenti isolati, validazione di ogni candidato, output strutturato, verifica indipendente e rapporto.

L'idea che regge tutto è una frase del post:

Se a un cacciatore permetti di correggere i propri compiti, convaliderà con sicurezza tutto quello che produce.

Per questo ogni candidato passa a un verificatore nuovo, che non ha partecipato alla caccia e ha il solo compito di smontarlo. Un risultato è "confermato" solo con una traccia completa nel sorgente e un effetto osservato; altrimenti resta "da validare", senza severità. Sul proprio parco di 128 repository Cloudflare è passata da 20.799 candidati grezzi a 7.245 segnalazioni consegnate ai team, e il tasso di rifiuto in validazione è sceso dal 40% all'11% man mano che migliorava il contesto passato ai verificatori. Un solo giro trova circa metà delle falle che trovano i giri ripetuti: la skill pubblica è il seme, il sistema completo non è ancora rilasciato.

Due limiti che la documentazione dichiara. Senza una sandbox imposta dal sistema operativo (rete chiusa, limiti di memoria, scritture confinate) la skill non esegue il codice analizzato, e le conclusioni che dipendono dal comportamento a runtime restano "da validare". E l'output sono rapporti, non patch: la correzione resta a chi legge.

L'ho vista al lavoro su un'applicazione Laravel di dimensioni medie, con il profilo rapido: mezz'ora e 19 agenti, quattro di ricognizione, quattro cacciatori, un critico e dieci verificatori, uno per candidato. Risultato: un problema confermato, otto piste da validare e una scartata con il motivo scritto.

Le piste non erano vaghe. Ognuna arrivava con la traccia nel sorgente, il fatto che il codice da solo non può dimostrare (il valore di una variabile d'ambiente in produzione, come il server web normalizza un URL) e un test già scritto per chiuderla in un minuto. Su macOS la sandbox manca, e tutto quello che dipendeva dal runtime è finito in quella colonna. È il comportamento giusto: un revisore che non sa, dice che non sa.

Anthropic e OpenAI hanno fatto la stessa scelta con prodotti chiusi. Claude Security è in beta pubblica da maggio 2026, e Anthropic sostiene che già il modello precedente aveva trovato più di 500 vulnerabilità gravi in codice open source passato per decenni sotto gli occhi degli esperti; a luglio è arrivato il plugin per Claude Code che fa la scansione in locale e propone le patch.

Codex Security, che si chiamava Aardvark, è in anteprima da marzo, e OpenAI dichiara un calo dei falsi positivi di oltre il 50% tra un giro e l'altro. Google con Big Sleep aveva pubblicato 20 vulnerabilità in progetti open source già nell'estate 2025.

Il filo comune non è il modello, è l'impalcatura attorno: un agente propone, un altro contesta, una persona decide. Che è esattamente quello che manca quando il modello scrive codice e nessuno lo legge.

Cosa cambia per chi scrive e revisiona codice

Le conclusioni pratiche le prendo dai rapporti, che su questo concordano.

Il codice generato è un contributo esterno non revisionato. Veracode lo scrive in chiaro, e la CSA lo traduce in regole: analisi statica (SAST, gli strumenti che leggono il sorgente a caccia di pattern pericolosi) e scansione dei segreti come passaggio obbligato prima del merge, non come controllo a campione.

La revisione va distribuita per rischio, non per righe. Autenticazione, autorizzazioni, crittografia e accesso ai dati sono le aree dove i modelli omettono, e sono quelle che richiedono un revisore che sappia cosa cercare. Una vista Blade e una policy di Laravel non meritano la stessa attenzione.

Le pull request vanno tenute piccole. Il dato di Apiiro sulle PR più grandi e più rare è quello che un team può correggere da solo, senza strumenti nuovi.

Le dipendenze suggerite vanno verificate. Un pacchetto proposto da un modello va cercato su Packagist o npm prima di installarlo, e un pacchetto creato da poco e con pochi download va guardato due volte.

L'iterazione cieca peggiora le cose. "Rendilo più veloce" ripetuto cinque volte produce codice più vulnerabile, lo dice lo studio sulle iterazioni. Ogni giro va letto.

Gli auditor automatici sono un secondo paio d'occhi, non il primo. La skill di Cloudflare e i prodotti di Anthropic e OpenAI costano token, non licenze, e trovano cose che una revisione umana lascia passare. Ma lavorano verificando candidati, e un candidato che nessuno ha letto resta un candidato.

Per chi lavora in PHP, con o senza Laravel, il consiglio in più è di non aspettare un benchmark che forse non arriverà: le tre righe dell'esempio sopra sono il minimo da cercare in ogni revisione.

Dove va a finire

Alla domanda del titolo la risposta onesta è che il codice scritto dall'AI è sicuro quanto il codice scritto in fretta da qualcuno che si fida di sé, cioè poco, con due differenze. La prima è il volume: ne arriva tre o quattro volte tanto. La seconda è la fiducia: lo studio di Stanford dice che chi lo usa lo crede più sicuro di quanto sia.

I numeri migliorano, ma sui frutti bassi. Il 62% di Veracode è arrivato correggendo l'XSS, mentre la log injection è ferma dal 2025 e le omissioni di autorizzazione non entrano in nessun benchmark. Non credo che un modello al 73% diventi uno al 95% nel 2027, perché il limite non è la capacità del modello: è che riproduce il codice che gli abbiamo dato in pasto.

Quello che cambia davvero è dove sta il collo di bottiglia. Scrivere codice costa poco, leggerlo costa quanto prima, e trovare le falle costa sempre meno sia a chi difende sia a chi attacca, come php2shell ha mostrato. Chi, nel vostro team, legge il codice che il modello ha scritto? Se la risposta è "nessuno, i test passano", il 38% è il vostro numero.