I pericoli nascosti nello scrivere codice con l’IA

Sebbene i vantaggi degli assistenti IA sul posto di lavoro siano sottoposti a scrutinio, l’area in cui vengono adottati con più baldanza è proprio lo sviluppo software. Qui gli LLM svolgono molti ruoli dal refactoring alla documentazione, passando dalla creazione di intere applicazioni. I tradizionali problemi di sicurezza delle informazioni nello sviluppo software sono di fatto aggravati dalle vulnerabilità tutte specifiche dei modelli di IA. Da questo incrocio di mondi emergono pressoché settimanalmente nuovi bug e problemi.

Codice vulnerabile generato dall’IA

Quando un LLM genera codice, può includere bug o falle di sicurezza. Dopotutto, questi modelli vengono addestrati in base a dati pubblicamente disponibili provenienti da Internet, inclusi migliaia di righe di codice di bassa qualità. Un recente studio di Veracode ha rilevato che i principali modelli di IA oggi producono codice compilato correttamente il 90% delle volte. Meno di due anni fa, questa cifra era inferiore al 20%. Tuttavia, la sicurezza nelle righe di codice non è migliorata: il 45% contiene ancora vulnerabilità classiche dell’elenco OWASP Top-10, senza sostanziali modifiche negli ultimi due anni. Lo studio ha riguardato oltre cento popolari LLM e frammenti di codice in Java, Python, C# e JavaScript. Pertanto, indipendentemente dal fatto che un LLM venga utilizzato per il “completamento del codice” in Windsurf o per il “vibe coding” in Loveable, l’applicazione finale deve essere sottoposta a test di vulnerabilità approfonditi. Ma nella pratica questo accade di rado: secondo uno studio di Wiz, il 20% delle app con vibe coding presenta vulnerabilità gravi o errori di configurazione.

Come esempio di tali difetti viene spesso citato il caso dell’app di incontri per sole donne Tea, diventata famosa dopo due importanti fughe di dati. Tuttavia, questa app è precedente al vibe coding. Se l’errore di Tea è dovuto all’IA sarà determinato in tribunale. Nel caso della startup Enrichlead, invece, il colpevole accertato è l’IA. Il suo fondatore si è vantato sui social media che il 100% del codice della piattaforma fosse scritto da Cursor AI, con “zero codice scritto a mano”. Pochi giorni dopo il lancio, è risultato essere pieno di falle di sicurezza degne di uno sviluppatore novellino, che consentivano a chiunque di accedere a funzionalità a pagamento o di alterare i dati. Il progetto è stato interrotto dopo che il fondatore non è riuscito a portare il codice a uno standard di sicurezza accettabile utilizzando Cursor. Tuttavia, rimane imperterrito nella propria condotta e da allora ha avviato nuovi progetti basati sul vibe coding.

Vulnerabilità comuni nel codice generato dall’IA

Sebbene la programmazione assistita dall’IA esista solo da un anno o due, abbiamo già dati sufficienti per identificarne gli errori più comuni. In genere si tratta di:

• Mancanza di convalida dell’input, mancata pulizia da caratteri estranei nell’input dell’utente e altri errori di base che conducono a vulnerabilità classiche come cross-site scripting (XSS) e iniezioni SQL.
• Chiavi API e altri segreti codificati direttamente nella pagina Web e visibili agli utenti nel relativo codice.
• Logica di autenticazione implementata interamente lato client, direttamente nel codice del sito in esecuzione nel browser. Questa logica può essere facilmente modificata per aggirare qualsiasi controllo.
• Errori di log: da un filtro di scrittura insufficiente alla completa assenza di log.
• Funzioni eccessivamente potenti e pericolose: i modelli di IA sono ottimizzati per generare codice che risolve un’attività nel modo più breve possibile. Ma la via più breve è spesso la meno sicura. Un esempio da manuale è l’uso della funzione eval per operazioni matematiche sull’input dell’utente, che apre le porte all’esecuzione di codice arbitrario nell’applicazione generata.
• Dipendenze obsolete o inesistenti. Il codice generato dall’IA spesso fa riferimento a versioni precedenti delle librerie, effettua chiamate API obsolete o non sicure o tenta persino di importare librerie fittizie. Quest’ultimo caso è particolarmente pericoloso perché utenti malintenzionati possono creare una libreria dannosa con un nome “plausibile” e l’agente di intelligenza artificiale la includerà senza tante storie in un progetto reale.

Uno studio sistematico ha scansionato il codice generato dall’IA per individuare i punti deboli inclusi nell’elenco dei top 25 di MITRE CWE. I problemi più comuni sono stati CWE-94 (iniezione di codice), CWE-78 (iniezione di comando del sistema operativo), CWE-190 (integer overflow), CWE-306 (authenticator mancante) e CWE-434 (caricamento di file senza restrizioni).

Un esempio lampante di CWE-94 è stata la recente compromissione della piattaforma Nx, di cui abbiamo già parlato. Gli aggressori sono riusciti a trojanizzare un popolare strumento di sviluppo rubando un token che consentiva loro di pubblicare nuove versioni del prodotto. Il furto di token sfruttava una vulnerabilità introdotta da un semplice frammento di codice generato dall’IA.

Suggerimenti pericolosi

Il noto detto tra gli sviluppatori “fatto esattamente secondo le specifiche” si applica anche quando si lavora con un assistente AI. Se la richiesta di creazione di una funzione o di un’applicazione è vaga e non menziona aspetti di protezione, la probabilità di generare codice vulnerabile aumenta notevolmente. Da uno studio dedicato è emerso che anche osservazioni generiche come “assicurarsi che il codice segua le migliori pratiche di protezione” hanno ridotto della metà il tasso di vulnerabilità.

L’approccio più efficace, tuttavia, consiste nell’utilizzare dettagliate linee guida di protezione specifiche per linguaggio e che fanno riferimento agli elenchi di errori MITRE o OWASP. Un’ampia raccolta di tali istruzioni di sicurezza di Wiz Research è disponibile in GitHub; è consigliabile aggiungerle ai prompt di sistema degli assistenti IA tramite file come claude.md, .windsurfrules o simili.

Degrado della sicurezza in fase di revisione

Quando il codice generato dall’IA viene rivisto ripetutamente tramite prompt di follow-up, la sua sicurezza peggiora. Un recente studio ha consentito a GPT-4o di modificare il codice scritto in precedenza fino a 40 volte, mentre i ricercatori scansionavano ogni versione alla ricerca di vulnerabilità a ogni giro. Dopo sole cinque iterazioni, il codice conteneva il 37% di vulnerabilità critiche in più rispetto alla versione iniziale. Lo studio ha testato quattro strategie di prompting, tre delle quali con un’enfasi diversa su (i) prestazioni, (ii) sicurezza e (iii) nuove funzionalità; la quarta strategia usava volontariamente suggerimenti poco chiari.

Quando il prompt si concentrava sull’aggiunta di nuove funzionalità, sono comparse 158 vulnerabilità, di cui 29 critiche. Quando il prompt si concentrava sulla protezione del codice, il numero è diminuito in modo significativo, ma includeva comunque 38 nuove vulnerabilità, sette delle quali critiche.

È interessante notare che i prompt “incentrati sulla sicurezza” hanno comportato la percentuale più alta di errori nelle funzioni di criptaggio.

Ignorare il contesto del settore

In settori quali finanza, assistenza sanitaria e logistica vigono requisiti tecnici, organizzativi e legali che devono essere considerati durante lo sviluppo di un’app. Gli assistenti IA non sono a conoscenza di questi vincoli. Questo problema è spesso chiamato “profondità mancante”. Di conseguenza, i metodi di archiviazione ed elaborazione dei dati personali, medici e finanziari richiesti dalle normative locali o di settore non si rifletteranno nel codice generato dall’IA. Ad esempio, un assistente potrebbe scrivere una funzione matematicamente corretta per il calcolo degli interessi sul deposito, ma ignorare le regole di arrotondamento imposte dalle autorità di regolamentazione. Le normative sui dati sanitari spesso richiedono una registrazione dettagliata di ogni tentativo di accesso, un’attività che l’IA non implementerà automaticamente al livello di dettaglio adeguato.

Errata configurazione dell’applicazione

Le vulnerabilità non si limitano al vibe coding. Le applicazioni create tramite il vibe coding sono spesso create da utenti inesperti, che non configurano affatto l’ambiente di runtime o lo fanno in base ai consigli della stessa IA. Questo porta a pericolosi errori di configurazione:

• I database richiesti dall’applicazione vengono creati con autorizzazioni di accesso esterno eccessivamente ampie. Questo si traduce in fughe di notizie come nel caso Tea/Sapphos, in cui l’utente malintenzionato non ha nemmeno bisogno di utilizzare l’applicazione per scaricare o eliminare l’intero database.
• Le applicazioni aziendali interne vengono lasciate accessibili al pubblico senza autenticazione.
• Alle applicazioni vengono concesse autorizzazioni elevate per l’accesso ai database critici. Insieme alle vulnerabilità del codice generato dall’IA, questo semplifica le iniezioni SQL e attacchi simili.

Vulnerabilità della piattaforma

La maggior parte delle piattaforme di vibe coding esegue le applicazioni generate dai prompt direttamente nei propri server. Questo lega gli sviluppatori alla piattaforma, inclusa l’esposizione alle relative vulnerabilità e la dipendenza dalle pratiche di sicurezza. Ad esempio, a luglio è stata scoperta una vulnerabilità nella piattaforma Base44 che consentiva a utenti malintenzionati non autenticati di accedere a qualsiasi applicazione privata.

Minacce in fase di sviluppo

La presenza stessa di un assistente con ampi diritti di accesso nel computer dello sviluppatore crea rischi. Ecco alcuni esempi:

La vulnerabilità CurXecute (CVE-2025-54135) consentiva agli utenti malintenzionati di ordinare a Cursor, il popolare strumento di sviluppo per l’IA, di eseguire comandi arbitrari nel computer dello sviluppatore. Tutto ciò di cui aveva bisogno era un server MCP (Model Context Protocol) attivo connesso a Cursor, che un utente esterno potesse utilizzare per l’accesso. Questa è una situazione tipica: i server MCP consentono agli agenti di intelligenza artificiale di accedere ai messaggi Slack, ai problemi di Jira e così via. L’iniezione di prompt può essere eseguita tramite uno qualsiasi di questi canali.

La vulnerabilità EscapeRoute (CVE-2025-53109) consentiva la lettura e la scrittura di file arbitrari sul disco dello sviluppatore. La falla si presentava nel popolare server MCP di Anthropic, che consente agli agenti di IA di scrivere e leggere i file nel sistema. Le restrizioni di accesso del server semplicemente non funzionavano.

Un server MCP dannoso che consentiva agli agenti di intelligenza artificiale di inviare e ricevere e-mail tramite Postmark inoltrava contemporaneamente tutta la corrispondenza a un indirizzo nascosto. Avevamo previsto l’emergere di tali server MCP dannosi a settembre.

Una vulnerabilità nell’interfaccia della riga di comando di Gemini consentiva l’esecuzione arbitraria di comandi quando uno sviluppatore chiedeva semplicemente all’assistente IA di analizzare il codice di un nuovo progetto. L’inserimento di contenuti dannosi veniva attivato da un file readme.md.

L’estensione Q Developer di Amazon per Visual Studio Code ha contenuto per breve tempo istruzioni per cancellare tutti i dati dal computer di uno sviluppatore. Un utente malintenzionato ha sfruttato un errore degli sviluppatori di Amazon ed è riuscito a inserire questo prompt dannoso nel codice pubblico dell’assistente senza privilegi speciali. Fortunatamente, un piccolo errore di codifica ne ha impedito l’esecuzione.

Una vulnerabilità nell’agente Claude Code (CVE-2025-55284) ha consentito l’esfiltrazione dei dati dal computer di uno sviluppatore tramite richieste DNS. L’iniezione di prompt, basata su utilità comuni eseguite automaticamente senza conferma, poteva essere incorporata in qualsiasi codice analizzato dall’agente.

L’agente di intelligenza artificiale autonomo Replit ha eliminato i database primari di un progetto in via di sviluppo perché aveva deciso che il database richiedeva una pulitura. Ciò ha violato un’istruzione diretta che vietava le modifiche (blocco del codice). Dietro questo comportamento inaspettato dell’IA si nasconde un difetto architetturale: all’epoca Replit non aveva separazione tra database di test e database di produzione.

Una prompt injection inserita in un commento al codice sorgente ha spinto l’ambiente di sviluppo Windsurf a memorizzare automaticamente istruzioni dannose nella propria memoria a lungo termine, agevolando il furto di dati dal sistema nell’arco di mesi.

Nell’incidente di compromissione Nx sono stati utilizzati gli strumenti della riga di comando per Claude, Gemini e Q per cercare password e chiavi passibili di furto da un sistema infetto.

Come usare l’intelligenza artificiale in modo sicuro

Il livello di rischio dovuto al codice generato dall’IA può essere ridotto in modo significativo, anche se non completamente, tramite una combinazione di misure organizzative e tecniche:

• Implementare la revisione automatica del codice generato dall’IA così come viene scritto utilizzando strumenti SAST ottimizzati.
• Integrare i requisiti di sicurezza nei prompt di sistema di tutti gli ambienti di IA.
• Fare in modo che specialisti umani eseguano revisioni dettagliate del codice, supportate da strumenti di analisi della sicurezza basati sull’intelligenza artificiale per aumentarne l’efficacia.
• Addestrare gli sviluppatori a scrivere prompt protetti e, più in generale, a fornire loro Kaspersky Automated Security Awareness Platform.