Il codice generato dall'AI è sicuro? I numeri del 2026, e il punto cieco degli scanner

Il codice generato dall'AI è sicuro?

No, non per impostazione predefinita. È sicuro quanto i controlli che gli stanno intorno, e quasi nessuna configurazione ne ha uno che agisca prima che il codice atterri. I benchmark indipendenti concordano sulla forma del fallimento: il codice gira, supera i suoi test e porta comunque una vulnerabilità. La sicurezza qui è una proprietà della tua pipeline, non del modello.

La misura sistematica più vecchia resta la più chiara. In Asleep at the Keyboard, sottomesso ad agosto 2021 da un gruppo della New York University con un coautore della University of Calgary, i ricercatori hanno sottoposto a GitHub Copilot 89 scenari costruiti sulle prime 25 debolezze del catalogo MITRE e hanno raccolto 1.689 completamenti. Il loro risultato, nelle loro parole: "Of these, we found approximately 40% to be vulnerable." Quel numero ha cinque anni e riguarda un solo assistente: è la linea di base, non il verdetto di oggi.

Il verdetto di oggi arriva da SusVibes, un benchmark del Language Technologies Institute della Carnegie Mellon University con collaboratori di Columbia, Johns Hopkins e HydroX AI, accettato a ICML 2026 e rivisto il 21 agosto 2026. Prende 186 richieste di funzionalità reali, estratte da progetti open source in cui l'implementazione umana era essa stessa vulnerabile, copre 79 categorie CWE e vi mette alla prova 12 configurazioni di agente. La migliore, SWE-Agent con Claude 4 Sonnet, è risultata funzionalmente corretta sul 57% dei task e sicura sull'11,8%. Il paper aggiunge la riga che dovrebbe preoccuparti di più: il 79,3% delle sue soluzioni funzionalmente corrette porta una vulnerabilità.

11,8%

delle soluzioni del miglior agente era sicuro, contro il 57% funzionalmente corretto (SusVibes, 186 richieste di funzionalità reali, revisionato ad agosto 2026)

79,3%

delle soluzioni funzionalmente corrette di quello stesso agente portava comunque una vulnerabilità (stesso benchmark)

100%

delle applicazioni testate da OWASP presentava una qualche forma di broken access control, il suo rischio numero uno per il 2025

È la scala a trasformare un tasso per task in un problema aziendale. Nel rapporto DORA 2025 sullo sviluppo software assistito dall'AI, pubblicato da Google Cloud il 23 settembre 2025, "90% of survey respondents report using AI at work" mentre "30% report little or no trust in the code generated by AI". Lo stesso rapporto annota che "AI adoption does continue to have a negative relationship with software delivery stability". Nove sviluppatori su dieci lo stanno spedendo, tre su dieci non se ne fidano, e la stabilità è il punto in cui quella tensione viene a galla. Una precisazione utile qui da noi: il DORA di questo rapporto è DevOps Research and Assessment, il programma di ricerca pubblicato da Google Cloud, e non il regolamento europeo che porta lo stesso acronimo.

Perché così tanto codice generato dall'AI è insicuro?

Perché un modello può possedere un principio di sicurezza e non applicarlo alla riga in cui quel principio conta. Una sistematizzazione di giugno 2026 della University at Buffalo ha dato un nome a questa distanza, knowledge-actuation gap, e l'ha misurata: i modelli vanno molto meglio nel conoscere la regola che nel produrre codice che sopravvive all'exploit corrispondente. Sapere non è fare.

Quel lavoro, SoK: AI Secure Code Generation, mette dei numeri sulla distanza. "The benchmark-level gap is 47.9 points for CWEval and 72.9 points for BaxBench", e il divario si allarga man mano che il task diventa realistico: CWEval lavora a livello di funzione, BaxBench chiede intere applicazioni web, dove la guardia deve atterrare nel middleware giusto, sulla route giusta, nel file giusto. Il tredicesimo insegnamento del paper è la frase da ricordare: lo scarto è un problema di consegna, perché i modelli possiedono la conoscenza di sicurezza corretta e non riescono ad applicarla al confine di implementazione corretto. Gli interventi che funzionano legano un principio già noto al punto giusto del codice, non insegnano altra sicurezza al modello.

Due forze più vecchie lo amplificano. Il problema del corpus: il modello ha imparato da una massa enorme di codice pubblico piena di SQL concatenato, controlli di autorizzazione mancanti, crittografia debole e segreti inline, quindi l'insicuro-per-default è il suo prior statistico. E il problema dell'assenza: la sicurezza è quasi sempre una guardia che è presente, e un modello a cui chiedi un esito positivo ("aggiungi un endpoint di checkout") non aggiunge una guardia negativa che nessuno gli ha chiesto. La funzionalità funziona proprio perché il controllo mancante non tocca il percorso felice.

Poi c'è il problema del lettore, ed è quello decisivo. Chi scrive il prompt sa dire se la funzionalità funziona, spesso non sa dire se è sicura. Quel divario, tra l'intento di chi scrive e la capacità di chi rivede, è l'intero problema della sicurezza, ed è ciò che si allarga quando una persona non specialista vibe-coda una funzionalità in un paragrafo di intento. Lo approfondiamo in sicurezza del vibe coding.

Che tipi di vulnerabilità introduce il codice generato dall'AI?

Le stesse che introducono gli esseri umani, riprodotte più in fretta di quanto la revisione riesca a tenere il passo. Injection, autorizzazione rotta, segreti hardcoded, validazione dell'input mancante, deserializzazione insicura ed errori di logica di business. Quasi tutte stanno nella CWE Top 25 del 2025, ed è il punto: non sono fallimenti esotici del modello, sono le debolezze più vecchie e meglio documentate del settore.

• Injection (CWE-89, CWE-78). SQL e comandi shell concatenati a partire dall'input dell'utente, perché il modello li ha imparati da un corpus che ne è pieno. L'SQL injection è seconda e la command injection sul sistema operativo nona nella CWE Top 25 del 2025. Vedi perché la maggior parte dei finding SAST è rumore per capire perché contano solo quelle raggiungibili.
• Autorizzazione rotta e IDOR (CWE-862, CWE-639). L'agente costruisce l'endpoint che restituisce il record, raramente il controllo che chi chiama ne sia il proprietario. L'autorizzazione mancante è quarta nella stessa lista, e OWASP mette la categoria madre al primo posto: A01:2025 Broken Access Control sta "maintaining its position at #1 in the Top Ten", con il "100% of the applications tested" che presenta una qualche forma di controllo di accesso rotto. Detto in termini che qui contano: un IDOR che restituisce la scheda di un altro cliente è un accesso non autorizzato a dati personali, quindi una violazione notificabile al Garante entro 72 ore ai sensi dell'articolo 33 del GDPR.
• Segreti hardcoded (CWE-798). Quando gli chiedi un'integrazione funzionante, il modello mette inline una chiave API o una password perché il codice giri al primo tentativo, e da lì quella vive nel repository e in ogni fork. Da notare: questa classe non compare nella CWE Top 25 del 2025, quindi non è lì che la troverai.
• Validazione dell'input mancante (CWE-20). Gli endpoint generati si fidano dei propri input, ed è l'abilitatore silenzioso di injection e deserializzazione a valle. Diciottesima nella lista del 2025.
• Deserializzazione insicura (CWE-502). "Carica l'oggetto salvato" diventa pickle o yaml.load su byte non attendibili, e un blob in archivio si trasforma in esecuzione di codice remoto. Quindicesima nella lista del 2025.
• Falle di logica di business. La classe più pericolosa, perché nessuno scanner è fatto per coglierla: un carrello con quantità negativa, un coupon che si cumula, un rimborso che salta il controllo di proprietà. Il codice è sintatticamente perfetto e semanticamente sbagliato, e non compare in nessuna classifica CWE perché è specifico del tuo dominio. Questo è il nostro approfondimento sulle falle di logica di business nel codice generato dall'AI.

Cosa sfugge agli scanner, e agli stessi modelli?

Due cose. La logica di business, che non offre nessun sink pericoloso da abbinare, e i punti ciechi del modello, che il modello stesso non può verificare finché sono al loro posto. SusVibes ha misurato il secondo in modo diretto: arricchire la richiesta di funzionalità con indizi di vulnerabilità non ha mitigato i problemi di sicurezza, quindi insistere nel prompt non è la soluzione.

Il primo punto cieco è la logica di business. Un analizzatore statico ragiona su pattern di codice; una regola di business ("solo il proprietario può modificare questo documento", "la quantità deve essere positiva") vive fuori dal codice, nel tuo dominio. Non c'è input contaminato né sink pericoloso da abbinare, solo un if che non è mai stato scritto, quindi lo scanner segnala il file come pulito mentre è pienamente sfruttabile.

Il secondo è il modello che si corregge i propri compiti. Chiedere allo stesso agente che ha scritto il codice di rivederlo eredita gli stessi punti ciechi: non conosce il tuo modello di autorizzazione, non vede gli altri finding intorno alla riga, ed è sicuro della versione insicura quanto di quella sicura. È di nuovo il knowledge-actuation gap, visto dal lato della revisione. Un controllo affidabile ha bisogno di segnale esterno: scansione consapevole della reachability che segue il flusso di dati reale, e le tue regole come verità di base, non l'opinione del modello su sé stesso.

“

La domanda non è se l'AI scriva codice insicuro, lo fa ogni autore. È se qualcosa colga la riga insicura prima che venga spedita, e alla velocità dell'AI l'unico posto rimasto per coglierla è dove la riga viene scritta.

Ci si può fidare di un'AI per correggere le proprie vulnerabilità?

Puoi fidarti di un agente per applicare una correzione molto più che per decidere che cosa sia una vulnerabilità reale e raggiungibile. Riscrive bene una riga quando sa con precisione cosa cambiare, e giudica male la sfruttabilità, che uno scanner maturo ha già calcolato. Quindi dagli i finding confermati e le tue regole, lascia che applichi la patch, approva ogni diff.

Il pattern affidabile non è "AI, rendi sicuro il mio codice", è "dai all'agente finding confermati e ordinati per reachability insieme alle tue regole, lascia che li corregga, e rivedi il risultato". Trattiamo quel loop in AI vulnerability remediation e nella domanda se un agente possa trovare e correggere le vulnerabilità automaticamente.

Quello che non funziona è scrivere le regole in un file e sperare. Nel nostro studio controllato del 24 agosto 2026, 30 ticket di sviluppo sono stati eseguiti in triplice copia su una codebase di medie dimensioni, 90 run autonome e 93 scansioni di sicurezza indipendenti, con Claude Opus 5 a effort alto. Un file di regole realistico mantenuto a mano nel repository ha implementato esattamente 7 specificità di regola su 55, il 13%, contro 8 su 65 senza alcun file, il 12%. Il file non ha cambiato quasi nulla. Le stesse regole consegnate al momento della modifica sono arrivate a 57 su 64, l'89%.

Lo studio pubblica anche i propri limiti, perché sono la parte utile: un ticket in cui il braccio senza strumenti ha fatto meglio, uno in cui la regola è stata servita tredici volte e l'agente ha comunque smontato le proprie guardie, e un protocollo che misura il mantenimento a zero su una codebase partita sana, non lo scavo in un arretrato esistente.

Come si rende sicuro il codice generato dall'AI?

Sposti il controllo al momento in cui il codice viene scritto, e dietro tieni scansione e revisione umana. Tre mosse, in ordine di leva: governa cosa scrive l'agente prima che lo scriva, riporta nel loop i finding confermati dagli scanner, e tieni come rete di sicurezza un gate in CI più una persona che approva i diff.

1. Governa al momento della generazione. Carica le tue regole di sicurezza e di business nell'agente prima di ogni modifica, così che il pattern sicuro sia il default a cui punta. La vulnerabilità che non viene mai scritta non ha bisogno di smistamento. È l'idea centrale di sicurezza degli agenti di codice AI.
2. Esegui scansioni in continuo e riporta i finding all'agente. Tieni in esecuzione SAST consapevole della reachability, SCA, segreti, IaC e CI/CD, e metti i loro finding confermati nelle mani dell'agente perché corregga quelli reali dentro il loop. Nel nostro studio i nuovi finding introdotti per task sono scesi da 0,10 senza strumento a 0,033 con il livello di governance, e il conteggio dello scanner indipendente è passato da 1 a 4 sul braccio non assistito su trenta ticket, mentre il braccio governato è rimasto a 1.
3. Tieni CI e revisione umana come rete di sicurezza. Un gate SAST su ogni pull request e una persona che approva i diff colgono ciò che sfugge. Sono necessari, ma alla velocità dell'AI non possono essere l'unica linea.

La versione pratica completa è come aggiungere sicurezza al tuo workflow di codifica AI e come proteggere un'intera app in cinque minuti.

VibeDefend è il livello che fa le prime due. È una CLI npm gratuita che si installa in pochi secondi e collega Claude Code, Cursor, Windsurf, OpenAI Codex e VS Code Copilot a quattro livelli di governance dentro il loop dell'agente.

Tre livelli governano ciò che l'agente scrive: Business Rules estratte dal tuo repository, Security Rules tratte dalle famiglie OWASP, SOC 2, GDPR e ISO 27001, e un Action Guard che blocca le chiamate distruttive. Il quarto, Live Findings, collega l'agente alla piattaforma di scansione di CybeDefend, con SAST, SCA, segreti, IaC e CI/CD in esecuzione continua e ogni finding vivo nel suo contesto, così l'agente non si limita a scrivere codice più sicuro, corregge le vulnerabilità che hai già. Niente del tuo codice attraversa la rete, passano solo metadati di governance strutturati, su regioni EU o US tenute fisicamente separate: conta quando devi documentare dove finiscono i dati.

Domande frequenti

Risposte brevi, ancorate alle fonti linkate qui sopra: lo studio della New York University su Copilot del 2021, il benchmark SusVibes revisionato ad agosto 2026, la sistematizzazione della University at Buffalo di giugno 2026, la OWASP Top 10:2025 e il nostro studio controllato del 24 agosto 2026.

Il codice generato dall'AI è sicuro?

Non per impostazione predefinita. Gira in modo affidabile e supera il percorso felice, ma i test indipendenti ne trovano ripetutamente una quota rilevante insicura: circa il 40% dei completamenti di Copilot era vulnerabile nello studio "Asleep at the Keyboard" della New York University del 2021, e nel benchmark SusVibes revisionato ad agosto 2026 la migliore configurazione di agente è stata funzionalmente corretta sul 57% di richieste di funzionalità reali mentre solo l'11,8% delle sue soluzioni era sicuro. Diventa sicuro quando aggiungi un controllo che agisce dove il codice viene scritto e dietro tieni revisione umana e scansione in CI.

È sicuro distribuire in produzione codice generato dall'AI?

Solo dopo che è stato rivisto e scansionato come va fatto per qualsiasi codice, e idealmente dopo che è stato governato mentre veniva scritto. Passare da "funziona" alla produzione è rischioso perché le falle (autorizzazione mancante, injection, segreti hardcoded, errori di logica di business) non toccano il percorso felice e sopravvivono a un test funzionale. SusVibes ha misurato quel divario: il 79,3% delle soluzioni funzionalmente corrette del miglior agente portava comunque una vulnerabilità. Mettilo dietro un gate con SAST consapevole della reachability in CI, revisione umana dei percorsi sensibili e un controllo al momento del prompt, così che la versione sicura venga scritta per prima.

Perché il codice generato dall'AI è insicuro se il modello è così capace?

Perché produrre codice funzionante non è la stessa cosa che produrre codice sicuro. La sistematizzazione della University at Buffalo di giugno 2026 chiama questa distanza knowledge-actuation gap e la misura in 47,9 punti su CWEval e 72,9 punti su BaxBench: il modello conosce il principio e non riesce ad applicarlo al confine di implementazione giusto. Aggiungi il corpus (il codice pubblico è pieno di pattern insicuri), l'assenza (la sicurezza è una guardia che nessuno ha chiesto) e il lettore (chi scrive il prompt spesso non sa valutarla). Nessuno di questi si risolve con un modello più intelligente.

Posso semplicemente chiedere all'AI di controllare il proprio codice per le vulnerabilità?

Aiuta un po' e non basta. Lo stesso modello che ha scritto il codice ne condivide i punti ciechi: non conosce il tuo modello di autorizzazione né il confine di tenant, non vede gli altri finding intorno alla riga, ed è ugualmente sicuro della versione insicura e di quella sicura. SusVibes ha testato la scorciatoia ovvia: arricchire la richiesta di funzionalità con indizi di vulnerabilità non ha mitigato i problemi di sicurezza. Un controllo affidabile ha bisogno di segnale esterno, scansione consapevole della reachability e le tue regole come verità di base.

Quali sono le vulnerabilità più comuni nel codice generato dall'AI?

Injection (CWE-89, CWE-78), autorizzazione rotta e IDOR (CWE-862, CWE-639), segreti hardcoded (CWE-798), validazione dell'input mancante (CWE-20), deserializzazione insicura (CWE-502) e falle di logica di business. Quattro di queste sei classi corrispondono a voci della CWE Top 25 del 2025, e OWASP mette il broken access control al primo posto per il 2025, riportando che il 100% delle applicazioni testate ne presentava una qualche forma. Le prime cinque sono rilevabili da buoni scanner quando filtri per reachability; l'ultima, la logica di business, è quella pericolosa perché nessuno scanner è fatto per cogliere una regola sintatticamente perfetta e semanticamente sbagliata.

Come rendo sicuro il codice generato dall'AI?

Sposta il controllo al momento della generazione: carica le tue regole di sicurezza e di business nell'agente così che scriva per primo il pattern sicuro, esegui scansioni in continuo e riporta i finding confermati all'agente perché li corregga, e tieni un gate SAST in CI più la revisione umana come rete di sicurezza. Scrivere le regole in un file del repository non basta: nel nostro studio controllato del 24 agosto 2026 un file di regole realistico ha implementato 7 specificità di regola su 55, il 13%, contro 8 su 65 senza alcun file, il 12%, mentre le stesse regole consegnate al momento della modifica sono arrivate a 57 su 64, l'89%.