La risposta breve
Nel luglio 2026, la società di sicurezza Theori ha lanciato la sua piattaforma di pentest autonomo Xint contro 28 applicazioni costruite con strumenti di coding IA e confermato 434 vulnerabilità sfruttabili — 196 in app costruite da zero e 238 in un singolo sistema legacy riscritto con l'aiuto dell'IA. L'aspetto sorprendente è la forma dei fallimenti. I modelli, distribuiti su cinque release di frontiera di Anthropic e OpenAI, erano chiaramente migliorati: la classica SQL injection e il cross-site scripting erano rari perché prepared statement e sanitizzazione degli input arrivavano di default. Ciò che mancava era tutto ciò che richiede una visione dell'intero sistema — rate limit assenti e query non limitate (denial of service), riferimenti agli oggetti non verificati (IDOR) e secret predefiniti incollati direttamente da template di avvio rapido.
Per i team che hanno integrato gli assistenti IA nello sviluppo quotidiano, la lezione non è «smettete di usarli». È che l'IA produce codice che sembra corretto e compila, mentre tralascia le proprietà di sicurezza che un architetto umano impone senza pensarci. Questo divario è economico da colmare con la revisione e costoso da ignorare — ecco perché il codice scritto da IA appartiene a un processo di sviluppo software sicuro, non va rilasciato direttamente dal prompt alla produzione.
Cosa ha testato Theori
Theori ha costruito lo studio attorno alla sua piattaforma Xint, che esegue test di penetrazione autonomi guidati da IA combinando il probing a runtime con l'analisi del codice sorgente. Il team l'ha puntata verso 28 applicazioni prodotte con diversi workflow di coding IA — da un prompt di una riga «costruiscimi un'app» a una generazione più strutturata, guidata da specifica — usando cinque modelli di frontiera di Anthropic e OpenAI. Ogni app ha ricevuto una scansione di circa 30 minuti. L'output grezzo era rumoroso: 8.827 rilevamenti potenziali. Dopo deduplica e triage di sfruttabilità, 434 problemi sono sopravvissuti come realmente sfruttabili, e sono questi i numeri che contano.
La divisione è istruttiva. Due app greenfield, generate da zero, totalizzavano 196 falle confermate. Ma un singolo caso brownfield — il forum PHP legacy Gnuboard7, migrato con l'aiuto dell'IA a uno stack Laravel e React — ne portava 238 da solo, più di entrambe le app greenfield messe insieme. È il segnale più chiaro del rapporto: le riscritture assistite da IA di sistemi esistenti non ereditano solo il vecchio rischio, lo moltiplicano mentre gli stessi controlli mancanti si ripetono su una superficie più ampia. Per chiunque stia valutando una modernizzazione di sistemi legacy accelerata da IA, è la riga da sottolineare prima di partire.
Quali bug l'IA ha lasciato
Il mix di vulnerabilità è la vera storia, perché vi dice dove cercare nel vostro codice generato da IA. L'esaurimento di risorse e il denial of service guidavano la lista con circa il 21 % dei rilevamenti — paginazione non limitata che restituisce un'intera tabella, endpoint senza rate limit e operazioni sincrone bloccanti che lasciano una singola richiesta occupare un worker. L'impatto, come lo ha inquadrato Theori, non sono dati rubati ma «costi server fuori controllo o un server che un attaccante può far cadere». Per un SaaS su cloud a consumo, è un incidente di fatturazione e di disponibilità insieme.
L'autorizzazione difettosa, soprattutto i riferimenti diretti non sicuri agli oggetti (IDOR), veniva dopo. Qui l'effetto dimensione è netto: circa l'11 % dei rilevamenti nelle piccole app greenfield, in salita a circa il 28 % nel CMS riscritto, perché l'IA applicava — o dimenticava — i controlli di proprietà in modo incoerente su centinaia di endpoint. I problemi di confine di fiducia come path traversal e server-side request forgery aggiungevano un'altra fetta. E tra le 23 falle di severità critica, lo schema che dovrebbe preoccupare ogni team è il più semplice: 11 erano secret in chiaro o predefiniti — valori SECRET_KEY predefiniti, chiavi di firma JWT e credenziali incorporate prese da template di avvio — più 6 casi di modalità debug lasciata attiva, che trasforma uno stack trace in esecuzione di codice remoto.
I risultati in sintesi
Le classi principali, tratte dall'insieme confermato di 434 problemi sfruttabili di Theori:
| Risultato | Cosa ha riportato Theori |
|---|---|
| App analizzate | 28 app generate da IA, 5 modelli di frontiera (Anthropic & OpenAI) |
| Grezzi → confermati | 8.827 rilevamenti filtrati a 434 sfruttabili |
| Greenfield vs brownfield | 196 in due app nuove; 238 in una app legacy riscritta da IA |
| Classe più comune | Esaurimento di risorse / DoS (≈21 %) |
| Seconda classe | Autorizzazione difettosa / IDOR (11 % piccola → 28 % grande) |
| Falle critiche | 23 totali — 11 secret in chiaro/predefiniti, 6 RCE in modalità debug |
| Gestiti bene | SQL injection e XSS — rari, grazie a prepared statement & sanitizzazione di default |
Perché il codice IA fallisce così
Lo schema non è casuale, e comprenderlo vi dice quale revisione dare per prioritaria. Un modello linguistico genera codice token per token dal contesto locale. È molto bravo sulla forma di una query di database sicura o di un template con escape, perché sono schemi locali e ripetuti che ha visto milioni di volte. È scarso sulle proprietà che esistono solo a livello dell'intero sistema: quale utente possiede questo record, quante righe questo endpoint dovrebbe mai restituire, quale rotta non deve mai girare con il debug attivo, dove si trova davvero il confine di fiducia tra i dati dei tenant. Sono fatti architetturali, non idiomi riga per riga.
Il CTO di Theori, Andrew Wesie, l'ha detto senza giri di parole: le «classi di vulnerabilità con cui i modelli faticano ancora sono quelle che richiedono una comprensione a livello di sistema». Questa singola frase dovrebbe rimodellare come i team si dividono il lavoro con l'IA. I modelli hanno guadagnato fiducia sui bug meccanici di tipo injection; non l'hanno guadagnata su autorizzazione, governance delle risorse o igiene dei secret. La raccomandazione stessa di Theori ne deriva direttamente — affidarsi a strumenti automatizzati per vagliare grandi volumi di codice generato da IA in cerca delle classi ricorrenti, e tenere gli esperti umani concentrati su threat modeling e architettura invece che sulla revisione riga per riga. È la stessa divisione del lavoro che integriamo nel modo in cui rilasciamo agenti e assistenti IA per i clienti: lasciare che il modello abbozzi, ma mai che sia l'ultimo paio di occhi su un confine di fiducia.
Cosa significa per i team in Italia & nell'UE
Vista dall'alto, lo studio è un avvertimento sulla velocità senza rete di sicurezza. Gli assistenti IA permettono a un piccolo team di rilasciare un'applicazione funzionante in pochi giorni, e ognuna delle 28 app funzionava — le falle erano invisibili finché un pentester autonomo non è andato a cercare. I team che misurano solo «gira?» accumulano un debito di sicurezza che non vedono, e il risultato brownfield mostra che quel debito si aggrava man mano che il codice cresce. La risposta non è uno sviluppo più lento; è rendere la revisione di sicurezza automatizzata una fase non negoziabile della pipeline, così che le classi DoS, IDOR e secret siano intercettate dalle macchine alla velocità con cui il codice viene scritto.
Per i prodotti regolamentati la posta è più alta di un ticket di bug. In FinTech e HealthTech, un IDOR che espone il record di un altro cliente è un evento di violazione dei dati con le scadenze citate. Una chiave di firma in chiaro in un repository pubblico è una divulgazione che aspetta solo il suo momento. L'AI Act europeo e framework come ISO 27001 e SOC 2 si aspettano già un ciclo di sviluppo documentato e controllato. I team che andranno veloci e resteranno conformi sono quelli che trattano l'output dell'IA come input non fidato di un vero secure-SDLC, non come lavoro finito.
Cosa fare questa settimana
Una sequenza breve e pratica che trasforma lo studio in azione anziché in ansia:
- Scansionare i secret nella CI. Aggiungete il rilevamento dei secret alla pipeline e bloccate i commit; ruotate ogni chiave mai comparsa nel codice sorgente o in un template. Questo neutralizza la più grande singola classe critica trovata dallo studio.
- Disattivare i default di sviluppo. Verificate ogni ambiente per modalità debug, errori verbosi e impostazioni di framework lasciate di default — la fonte delle RCE in modalità debug.
- Testare il carico e limitare il rate. Aggiungete rate limit, tetti di paginazione e timeout agli endpoint generati da IA; sondate le query non limitate prima che lo faccia un attaccante o una bolletta cloud.
- Rivedere l'autorizzazione a mano. L'IDOR è esattamente ciò che l'automazione manca e ciò che cresce con la scala — fate verificare da un umano i controlli di proprietà su ogni endpoint che restituisce dati utente.
- Fare dell'AppSec una fase della pipeline. Mettete la revisione di sicurezza automatizzata prima del merge del codice scritto da IA, e instradate tutto ciò che tocca un confine di fiducia verso un responsabile umano.
Niente di tutto questo è un argomento contro gli strumenti di coding IA — il caso della produttività è reale, e i modelli hanno davvero chiuso la porta ai bug di injection che hanno afflitto una generazione di app. Ma lo studio è un segnale chiaro: l'IA scrive codice che supera una demo, non codice che sopravvive a un attaccante. I team che aggiungono lo strato di revisione mancante ottengono entrambi — velocità e sicurezza; quelli che lo saltano rilasciano app da 434 falle senza saperlo.
Domande frequenti
Cosa ha rilevato lo studio Theori sul codice generato da IA?
Theori ha lanciato la sua piattaforma di pentest autonomo Xint contro 28 app costruite con strumenti IA su cinque modelli di frontiera di Anthropic e OpenAI, ha filtrato 8.827 rilevamenti grezzi e confermato 434 vulnerabilità sfruttabili — 196 in app greenfield e 238 in una app legacy riscritta da IA. Il DoS per esaurimento di risorse guidava, seguito dall'autorizzazione difettosa; delle 23 falle critiche, 11 erano secret in chiaro o predefiniti e 6 RCE in modalità debug.
Perché il codice generato da IA contiene falle di sicurezza?
I modelli gestivano bene SQL injection e XSS con prepared statement e sanitizzazione, ma faticano sul ragionamento a livello di sistema — confini di fiducia, limiti di risorse e proprietà dei dati. Per questo omettono i rate limit, lasciano i riferimenti agli oggetti non verificati (IDOR) e incollano secret predefiniti dai template. Come ha notato il CTO di Theori Andrew Wesie, le classi difficili sono quelle che richiedono una comprensione a livello di sistema.
Le vulnerabilità peggiorano nelle basi di codice IA più grandi?
Sì. L'IDOR compariva in circa l'11 % dei rilevamenti nelle piccole app greenfield ma saliva a circa il 28 % nel CMS riscritto, dove la stessa falla si ripeteva su centinaia di endpoint. La singola app brownfield portava 238 falle confermate — più di entrambe le app greenfield messe insieme (196) — mostrando che le riscritture assistite da IA concentrano il rischio man mano che l'ambito cresce.
È sicuro usare strumenti di coding IA in produzione?
Sì, con revisione. Il guadagno di produttività è reale e i modelli gestiscono i comuni bug di injection, ma il loro output non dovrebbe essere rilasciato senza revisione. Mantenete il codice scritto da IA in un SDLC sicuro: revisione di sicurezza automatizzata ad alto volume per i ricorrenti problemi di DoS, autorizzazione e secret, più ingegneri umani responsabili del threat modeling e dell'architettura, dove i modelli falliscono.
Cosa dovrebbero fare i team contro i secret in chiaro nelle app generate da IA?
I secret in chiaro e predefiniti erano quasi la metà delle falle critiche. Aggiungete lo scanning dei secret alla CI per bloccare i commit, spostate le chiavi in un secrets store gestito o in un'iniezione da environment, ruotate ogni credenziale mai comparsa nel codice sorgente o in un template, e non lasciate mai che un default di sviluppo di un framework raggiunga la produzione. Sono controlli economici e automatizzabili che rimuovono la classe più grave trovata dallo studio.
Fonti
SecurityWeek — Vibe-Coded Apps Riddled With Exploitable Security Flaws, 22 luglio 2026
Help Net Security — The AI code vulnerabilities that grow with your app, 23 luglio 2026
Cybersecurity News — What 434 AI-Generated Vulnerabilities Reveal About Secure Software Development, luglio 2026