Codice generato dall’AI: quasi metà è insicuro, e la velocità nasconde il debito

Il codice generato dall’AI ha smesso di essere una curiosità da laboratorio ed è entrato nel flusso di lavoro quotidiano di gran parte degli sviluppatori, spesso senza che l’organizzazione se ne sia accorta davvero. La promessa è evidente e reale: scrivere più in fretta, delegare le parti ripetitive, abbassare la barriera d’ingresso a chi programma poco. Il problema è che la sicurezza non è migliorata alla stessa velocità della produttività, e i numeri cominciano a dirlo con precisione. Il Veracode GenAI Code Security Report, nella sua prima edizione del luglio 2025, ha messo alla prova oltre cento modelli su ottanta compiti in cui esisteva sia una via sicura sia una insicura, e ha misurato una cosa precisa: nel 45% dei casi il modello sceglie la via insicura.

Il dato più scomodo non è la percentuale in sé, ma la sua ostinazione. L’aggiornamento di primavera 2026 del report, esteso a oltre 150 modelli tra cui i più recenti (GPT-5.1 e 5.2, Gemini 3, Claude 4.5 e 4.6), fotografa la stessa situazione di due anni prima: solo il 55% del codice generato è sicuro, mentre la correttezza sintattica ha ormai superato il 95%. I modelli hanno imparato benissimo a produrre codice che funziona e compila, e questo genera fiducia; la stessa fiducia non è però giustificata sul piano della sicurezza, dove i progressi sono stati minimi. Va detta un’eccezione, per onestà: la famiglia GPT-5 con reasoning esteso ha toccato, nella rilevazione dell’ottobre 2025, il tasso più alto mai registrato, tra il 70 e il 72%, ma le release successive non hanno consolidato il vantaggio, restando nel margine d’errore dei modelli precedenti. E anche quel picco lascia vulnerabile quasi un frammento di codice su tre, lontano da un livello accettabile in produzione. Chi accetta un suggerimento perché “gira” sta valutando la funzionalità, non la resistenza a un attacco, e il modello ha ottimizzato esattamente per la prima cosa.

Perché il codice generato dall’AI è insicuro per default

La radice del problema è nel modo in cui questi modelli imparano. Un large language model è addestrato su enormi quantità di codice pubblico, che include tanto le buone pratiche quanto gli esempi vulnerabili, i tutorial semplificati e le scorciatoie insicure che popolano forum e repository. Il modello non distingue il codice sicuro da quello pericoloso: riproduce ciò che è statisticamente plausibile nel contesto, e il pattern insicuro spesso è più frequente di quello corretto. Manca inoltre la cosa che un buon sviluppatore porta con sé, cioè il contesto di minaccia: chi userà questa funzione, con quali input ostili, in quale posizione della superficie d’attacco.

Il dato di addestramento, però, spiega solo una parte, e i numeri dell’aggiornamento 2026 mostrano dove il problema si concentra davvero. I modelli non sbagliano ovunque: sulla SQL injection il codice sicuro sale all’82% e sugli algoritmi crittografici deboli all’86%, perché sono vulnerabilità riconoscibili come pattern locali, viste e riviste etichettate come insicure. Crollano invece dove serve seguire un input non fidato attraverso più funzioni, trasformazioni e file fino al punto in cui viene usato: sul cross-site scripting solo il 15% del codice supera i controlli, sulla log injection appena il 13%, e su queste categorie Veracode segnala che la tendenza sta perfino peggiorando. È la differenza tra riconoscere una forma e ricostruire un contesto, cioè l’analisi di dataflow interprocedurale, difficile da fare in modo consistente perfino per una persona esperta. Non a caso il linguaggio peggiore è Java, fermo al 29% di codice sicuro contro il 62% di Python, e non a caso i modelli con reasoning recuperano qualcosa, perché i passaggi di ragionamento funzionano come una revisione interna del codice. Non è dunque un limite che la prossima generazione di modelli risolverà da sé: è strutturale, legato al tipo di analisi che manca, non alla potenza di calcolo.

Non è (solo) un problema di bug: il debito di sicurezza su scala

La differenza rispetto al passato non è la singola vulnerabilità, che c’è sempre stata, ma la scala e la velocità con cui si moltiplica. Lo ha misurato in produzione Apiiro, su decine di migliaia di repository di aziende Fortune 50 tra dicembre 2024 e giugno 2025: gli sviluppatori assistiti dall’AI committano da tre a quattro volte più spesso e generano circa dieci volte più problemi di sicurezza, con gli errori di sintassi in calo del 76% ma i difetti architetturali in aumento del 153%. È, in numeri di produzione, esattamente la tesi di partenza: codice più corretto in superficie e più fragile nella struttura. Lo stesso pattern insicuro, generato una volta, viene poi replicato in decine di punti prima che qualcuno lo riveda, e si aggiungono modalità di errore nuove: segreti e chiavi lasciati in chiaro nel codice suggerito, e soprattutto le dipendenze inventate di sana pianta dal modello, un vettore di supply chain a sé, lo slopsquatting. Uno studio di USENIX Security 2025 (Spracklen et al., We Have a Package for You!, University of Texas at San Antonio), su 576.000 campioni e sedici modelli, ha trovato che circa un campione di codice su cinque, in Python e JavaScript, referenzia pacchetti inesistenti, e che il 43% di quei nomi allucinati si ripresenta identico su prompt simili: è la riproducibilità, non l’allucinazione in sé, a rendere possibile l’attacco, perché consente all’aggressore di registrare in anticipo il pacchetto che il modello inventerà.

C’è poi la dimensione umana, che amplifica tutto il resto ed è la parte del problema più facile da sottovalutare. Un sondaggio Snyk del 2023 su oltre 500 professionisti rilevava che oltre il 75% riteneva il codice generato dall’AI più sicuro di quello scritto dall’uomo. È una percezione autodichiarata, non una misurazione, e uno studio controllato di Stanford presentato ad ACM CCS nel 2023 ha mostrato l’opposto: chi lavorava con un assistente ha consegnato codice significativamente meno sicuro, ed era al tempo stesso più convinto di averlo scritto sicuro. Nello stesso esperimento, chi si fidava meno dell’assistente e rilavorava i prompt produceva codice con meno vulnerabilità. È il cortocircuito che allenta la revisione critica proprio dove servirebbe di più. Quando poi l’adozione avviene fuori da ogni processo (sviluppatori che incollano codice da assistenti personali senza che l’azienda lo sappia), si entra nel territorio della shadow AI, dove il debito non è nemmeno misurabile perché nessuno sa dove e quanto se ne stia accumulando.

Il tracciamento indipendente conferma che il problema è già reale e non teorico. Il cruscotto del Vibe Security Radar, progetto avviato nel maggio 2025 dal Systems Software & Security Lab del Georgia Tech, al 24 marzo 2026 riporta 78 vulnerabilità pubbliche riconducibili all’AI, 43 delle quali classificate come critiche o gravi, su 46.831 advisory analizzati. Ma il segnale vero è l’accelerazione: dalle 6 nuove CVE di gennaio 2026 alle 15 di febbraio alle oltre 35 del solo marzo, un mese in cui i casi hanno superato quelli di tutto il 2025. E il ricercatore che guida il progetto stima il sommerso da cinque a dieci volte più grande, perché molti commit assistiti dall’AI non lasciano tracce nei metadati.

Dalla generazione alla verifica: dove mettere i controlli

La risposta non è vietare gli assistenti, che porterebbe solo più shadow AI, ma trattare il loro output per quello che è: codice non fidato per default, da sottoporre alla stessa verifica che si applicherebbe al contributo di uno sviluppatore junior molto veloce e molto sicuro di sé. La disciplina, in fondo, esiste già ed è quella del secure coding: analisi statica e dinamica nella pipeline, scansione dei segreti prima del commit, verifica delle dipendenze contro l’esistenza reale e la reputazione del pacchetto, revisione umana obbligatoria sui punti critici. Ciò che cambia è che questi controlli non possono più essere occasionali, perché il volume da controllare è esploso.

Il punto operativo è quindi spostare i controlli dove reggono la scala, cioè automatizzarli e inserirli nel flusso, secondo la logica del DevSecOps: far fallire la build quando la vulnerabilità supera una soglia, non affidarsi alla buona volontà di chi rivede a valle. Vale la pena distinguere due livelli. Il primo è tecnico e riguarda i gate automatici nella pipeline; il secondo è di governo e riguarda le regole d’uso, cioè quali strumenti sono ammessi, su quali basi di codice, con quale tracciabilità di ciò che è stato generato. Senza il secondo livello, il primo copre solo il codice che passa dai canali ufficiali, e lascia scoperto proprio quello più rischioso.

L’obbligo non cambia se a scrivere è una macchina

C’è una ragione normativa, oltre che tecnica, per non trattare l’AI come una scusante. Gli obblighi di sicurezza del prodotto non guardano a chi ha scritto materialmente il codice. Il Cyber Resilience Act impone sicurezza by design, gestione delle vulnerabilità e trasparenza sulle componenti per i prodotti con elementi digitali, a prescindere dal fatto che una parte del codice sia stata generata da un modello. La piena applicazione è fissata all’11 dicembre 2027, ma il primo obbligo che tocca direttamente i fabbricanti scatta prima: dall’11 settembre 2026 dovranno segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi, con allarme rapido entro 24 ore e notifica completa entro 72. Un difetto introdotto da un assistente resta, sul piano della responsabilità, un difetto del produttore: l’automazione della scrittura non trasferisce l’automazione della responsabilità.

Cosa aspettarsi, senza illusioni

Il codice generato dall’AI non è un rischio da rimuovere ma una realtà da governare: è già nel processo di sviluppo, produce valore, e continuerà a diffondersi. Trattarlo come infallibile perché appare competente è però l’errore che i dati smentiscono con più nettezza, dal 45% di scelte insicure misurato nel benchmark, un dato fermo da due anni, alle vulnerabilità già ricondotte a questi strumenti nel mondo reale. Il vero pericolo non è il singolo suggerimento sbagliato, ma la velocità che supera la verifica: quando si genera più in fretta di quanto si riesca a controllare, il debito di sicurezza si accumula dove nessuno lo sta guardando. La via d’uscita non è rallentare né vietare, ma portare la verifica alla stessa scala della generazione, con controlli automatici e regole d’uso chiare. In quell’equilibrio, tra velocità dell’AI e rigore della verifica, si decide se il codice generato dall’AI sarà un moltiplicatore di produttività o un moltiplicatore di esposizione.