Sicurezza del codice generato dall’IA: i rischi e come revisionarlo

Quali sono i rischi di sicurezza del codice generato dall’IA?

Gli assistenti e gli agenti di programmazione scrivono codice prevedendo ciò che di solito viene dopo, sulla base del codice esistente. Questo li rende veloci, ma significa anche che ripetono ciò che era comune in quel codice, comprese vecchie versioni delle librerie, API deprecate e abitudini poco sicure. Un modello non sa quale release di un pacchetto è stata corretta il mese scorso, a meno che non vada a verificarlo, e un agente in grado di eseguire comandi può installare ciò che suggerisce prima che qualcuno legga la modifica.

Nessuno di questi rischi è nuovo di per sé. A cambiare sono il volume e la velocità: più codice, più dipendenze nuove e meno persone che leggono ogni riga. La risposta è applicare in automatico i controlli che applicheresti a qualsiasi contributo esterno, così che non vengano saltati quando il diff è corposo.

• Versioni di dipendenze obsolete o con vulnerabilità note, suggerite a partire dai dati di addestramento.
• Nomi di pacchetti che non esistono, o che un attaccante ha registrato proprio perché i modelli tendono a inventarli.
• Pacchetti malevoli pubblicati di recente, compresi nomi che imitano quelli di librerie popolari.
• Segreti incollati nel codice o nella configurazione: chiavi API, token, stringhe di connessione.
• Pattern non sicuri, come query SQL o comandi di shell costruiti concatenando stringhe, verifiche dei certificati disattivate o crittografia debole.
• Agenti con permessi ampi che installano pacchetti, eseguono script o fanno il push di modifiche senza revisione.

Che cos’è lo slopsquatting?

Lo «slopsquatting» consiste nel registrare un pacchetto con un nome che i modelli di IA tendono a inventare, così che chiunque installi quel nome inventato ottenga il codice dell’attaccante. Il termine unisce «slop», in gergo l’output di bassa qualità generato dalle macchine, e typosquatting, la pratica con cui gli attaccanti registrano storpiature dei nomi di pacchetti popolari. Funziona perché i registri pubblici come npm e PyPI permettono a chiunque di pubblicare con un nome che nessuno ha ancora rivendicato.

Uno studio sottoposto a revisione paritaria e presentato a USENIX Security 2025 ha testato 16 modelli di generazione di codice e prodotto 576.000 campioni di codice. Gli autori riportano che la quota media di pacchetti allucinati è stata di almeno il 5,2 % per i modelli commerciali e del 21,7 % per i modelli open source, e hanno raccolto 205.474 nomi di pacchetti inventati unici. Ripetendo dieci volte lo stesso prompt, un nome inventato è ricomparso più di una volta nel 58 % dei casi, ed è questo a rendere tali nomi abbastanza prevedibili da poter essere registrati.

Il progetto OpenSSF Malicious Packages pubblica, nel formato OSV, le segnalazioni di pacchetti malevoli trovati nei registri open source, con identificatori che iniziano con MAL-. Confrontare le dipendenze con questo database intercetta i pacchetti già segnalati. Non può intercettare un pacchetto registrato ieri che nessuno ha ancora analizzato, quindi va affiancato alla verifica che un pacchetto esista, di chi lo pubblica e da quanto tempo è disponibile. Questa verifica, nel momento in cui un agente propone un pacchetto, è nella roadmap di KROMSE.

Come revisionare il codice scritto dall’IA prima del merge

L’obiettivo è una routine che funzioni allo stesso modo sia che la modifica l’abbia scritta una persona sia che l’abbia scritta un agente. Gran parte può stare nella pipeline che già esegue i tuoi test; la parte umana consiste nel leggere il diff con lo scetticismo che riserveresti alla pull request di uno sconosciuto. OpenSSF pubblica una guida alle istruzioni orientate alla sicurezza per gli assistenti di programmazione, un utile punto di partenza per i prompt stessi.

• Fai il commit dei lockfile e installa a partire da quelli nella CI, così le versioni revisionate sono le stesse che distribuisci.
• Fissa versioni esatte per le nuove dipendenze e rivedi ogni modifica al lockfile, non solo al manifest.
• Verifica che ogni nuovo pacchetto esista, sia quello che intendevi e che chi lo pubblica e la sua cronologia siano verificabili.
• Mantieni una lista di pacchetti approvati (allowlist), oppure installa tramite un proxy interno del registro che blocchi tutto il resto.
• Esegui analisi del codice sorgente, ricerca di segreti e controlli sulle dipendenze a ogni modifica, e blocca il merge in presenza di nuove rilevazioni critiche.
• Richiedi un revisore designato per le modifiche scritte dall’IA e non permettere agli agenti di fare merge o deploy da soli.

Il codice scritto dall’IA cambia i tuoi obblighi ai sensi del Cyber Resilience Act?

Il Cyber Resilience Act, il regolamento sulla ciberresilienza, pone i suoi obblighi in capo al fabbricante di un prodotto con elementi digitali. Il suo considerando 34 precisa che gli obblighi di gestione delle vulnerabilità si applicano al prodotto nella sua interezza, compresi tutti i componenti integrati. L’articolo 13, paragrafo 5, chiede di esercitare la dovuta diligenza quando si integrano componenti di terzi, compresi quelli open source, e l’allegato I, parte II, chiede ai fabbricanti di identificare e documentare i componenti, anche con una distinta base del software (SBOM), e di effettuare prove e riesami efficaci e periodici della sicurezza del prodotto.

In pratica, una dipendenza aggiunta da un agente è un componente di terzi come qualsiasi altro, e una vulnerabilità che introduce spetta a te gestirla per tutto il periodo di assistenza. Gli obblighi di segnalazione dell’articolo 14 si applicano dall’11 settembre 2026; la maggior parte degli altri obblighi si applica dall’11 dicembre 2027.

Cosa intercettano i controlli automatici e cosa sfugge loro

I database di vulnerabilità conoscono le vulnerabilità che sono state segnalate, e un database di pacchetti malevoli conosce i pacchetti che qualcuno ha analizzato. L’analisi del codice sorgente trova pattern rischiosi noti, come una query costruita a partire dall’input dell’utente, ma non una regola di business sbagliata o un controllo dei permessi mancante che sembra codice qualsiasi. Cercare segreti nel codice attuale non rileva una chiave che è stata committata e poi cancellata, perché resta nella cronologia di git.

Per questo una routine di revisione combina più controlli con una persona che legge la modifica. Quando uno strumento non segnala nulla, registra ciò che non ha potuto vedere, così che «nessuna rilevazione» non venga letto come «nessun rischio». Per il codice scritto dall’IA, le lacune maggiori sono i pacchetti troppo recenti per comparire in qualsiasi database e i nomi che non esistevano finché un modello non li ha suggeriti.

Domande frequenti

Fonti

• Spracklen et al., «We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs», USENIX Security 2025
• OpenSSF Best Practices Working Group: guida alle istruzioni orientate alla sicurezza per gli assistenti di programmazione IA (in inglese)
• Repository OpenSSF Malicious Packages
• OpenSSF: rilevare i pacchetti malevoli con l’API di OSV (in inglese)
• Regolamento (UE) 2024/2847 (regolamento sulla ciberresilienza)