Modelli LLM e vulnerabilità: l’IA nel codice software

Come i modelli LLM introducono vulnerabilità nel codice software

I modelli di linguaggio di grandi dimensioni generano codice attraverso un processo statistico: predicono il token successivo più probabile basandosi sul contesto del prompt e sui pattern appresi durante il training.

Questo processo è straordinariamente efficace per produrre codice funzionalmente corretto in scenari comuni, ma ha limitazioni strutturali quando si tratta di sicurezza. La sicurezza richiede non solo che il codice faccia ciò che deve fare, ma che non faccia ciò che non deve: una proprietà negativa che è molto più difficile da apprendere da esempi statistici che da specifiche formali.

Ricerche accademiche indipendenti hanno documentato che una percentuale significativa del codice generato dagli LLM contiene vulnerabilità di sicurezza, con tassi che variano significativamente in funzione del tipo di task (le operazioni crittografiche e la gestione dell’input utente sono le aree più problematiche), del modello utilizzato e della qualità del prompt fornito dallo sviluppatore.

Il problema non è l’eccezione: è una caratteristica strutturale dei modelli attuali che i team di sviluppo devono imparare a gestire sistematicamente.

Il rischio di generazione di codice insicuro o obsoleto da parte dell’IA

I modelli LLM sono addestrati su corpus di codice che includono repository pubblici, documentazione tecnica e forum come Stack Overflow: tutti dataset che riflettono lo stato della conoscenza collettiva al momento della raccolta, non le best practice di sicurezza attuali.

Questo crea un problema di obsolescenza: un modello addestrato su dati con cutoff nel 2023 può generare codice che usa API deprecate, librerie con vulnerabilità note o pattern crittografici considerati insicuri: ad esempio MD5 per l’hashing delle password, ECB mode per la crittografia AES, query SQL costruite con concatenazione di stringhe invece di prepared statements.

Il problema è amplificato dalla natura statistica dell’apprendimento: se il 70% degli esempi di codice di autenticazione nel corpus di training usa hash MD5 (perché è il pattern più vecchio e quindi più rappresentato), il modello tenderà a riprodurre questo pattern anche quando esistono alternative più sicure.

Lo sviluppatore che accetta il codice generato senza una revisione critica introduce in produzione una vulnerabilità che il modello ha imparato da anni di cattive pratiche documentate su internet.

La familiarità con il pattern, che appare identico a codice visto migliaia di volte, rende la vulnerabilità ancora più difficile da rilevare nella review.

Allucinazioni dei modelli e importazione di librerie dannose o inesistenti

Le allucinazioni, ossia la tendenza dei modelli LLM a generare informazioni plausibili ma false, rappresentano una categoria di rischio specifica e particolarmente insidiosa nel contesto dello sviluppo software.

Quando un LLM ha un’allucinazione su un’API di una libreria reale, il risultato è un errore di compilazione immediatamente visibile. Quando l’allucinazione è sul nome di un pacchetto npm, PyPI o RubyGems che non esiste, il risultato può essere molto più pericoloso.

Il fenomeno del «package hallucination», documentato da ricercatori di Vulcan Cyber e confermato da studi successivi, consiste nella generazione di nomi di pacchetti plausibili ma inesistenti nelle istruzioni di import del codice generato.

Se uno sviluppatore installa il pacchetto suggerito senza verificarne l’autenticità, può finire per installare un pacchetto malevolo creato appositamente per sfruttare le allucinazioni degli LLM.

L’attacco è noto come AI package hallucination attack o slopsquatting: un attore malevolo registra in anticipo i nomi di pacchetti che i modelli LLM tendono ad allucinare, caricandovi codice malevolo che viene poi installato da sviluppatori ignari.

La ricerca pubblicata da Lanyado et al. nel 2023 ha dimostrato che i modelli LLM più diffusi allucinano nomi di pacchetti con una frequenza non trascurabile, con tassi che variano tra il 5% e il 20% a seconda del modello e del contesto, e che molti dei nomi allucinati corrispondono a pacchetti già registrati nei repository pubblici, aumentando il rischio di confusione.

Questo vettore di attacco è particolarmente efficace perché bypassa completamente le difese tradizionali: il codice sembra legittimo, il pacchetto esiste nel repository, e l’installazione avviene attraverso i canali ufficiali.

Principali minacce di sicurezza secondo il framework OWASP per LLM

OWASP, l’Open Web Application Security Project, ha pubblicato nel 2023 la prima versione del framework LLM AI Security Top 10, aggiornato nel 2025, che identifica le dieci minacce di sicurezza più significative associate all’integrazione dei modelli LLM nelle applicazioni.

Il framework si è rapidamente affermato come riferimento de facto per i team di sicurezza che devono valutare i rischi dell’adozione degli LLM, analogamente a quanto l’OWASP Top 10 tradizionale ha fatto per le vulnerabilità delle applicazioni web.

Le dieci categorie coprono sia i rischi interni agli LLM (allucinazioni, training data poisoning, model theft) sia i rischi derivanti dall’integrazione degli LLM nelle applicazioni (prompt injection, insecure output handling, excessive agency).

Attacchi di prompt injection e manipolazione del comportamento del software

La prompt injection è la vulnerabilità più critica e più studiata nel contesto degli LLM integrati nelle applicazioni.

A differenza della SQL injection, che inserisce comandi malevoli in una query strutturata, la prompt injection inserisce istruzioni malevole nel testo naturale che viene passato al modello come parte del contesto o dell’input utente.

L’attacco sfrutta l’incapacità intrinseca dei modelli LLM di distinguere le istruzioni del sistema dalle istruzioni dell’utente finale: entrambe sono testo naturale, e il modello le elabora seguendo il pattern statistico più probabile, che può essere influenzato da istruzioni iniettate con sufficiente forza.

Le forme più pericolose di prompt injection nelle applicazioni che integrano LLM per generazione o revisione di codice sono quelle che portano il modello a generare codice con backdoor deliberate, a modificare le istruzioni di sicurezza ricevute dal sistema o a esfiltrare informazioni contenute nel contesto della conversazione (dati dell’utente, chiavi API passate nel prompt, istruzioni del sistema che dovrebbero essere riservate).

L’attacco indiretto, o indirect prompt injection, è particolarmente insidioso: l’input malevolo non viene dall’utente direttamente, ma da contenuto esterno che l’LLM processa come parte del task (un documento da analizzare, un sito web da riassumere, un file di codice da revisionare) che contiene istruzioni nascoste progettate per modificare il comportamento del modello.

Data leakage e esposizione di informazioni sensibili tramite i dati di addestramento

I modelli LLM di grandi dimensioni possono memorizzare e riprodurre porzioni dei loro dati di addestramento in risposta a prompt opportunamente costruiti: un fenomeno noto come memorization.

Studi su GPT-2 e GPT-3 hanno dimostrato che i modelli possono riprodurre sequenze esatte di testo presente nel corpus di training, inclusi dati personali, indirizzi e-mail, numeri di telefono e altri dati sensibili presenti in documenti pubblici usati per il training.

Quando un’organizzazione fa fine-tuning di un modello LLM su dati proprietari (codice sorgente interno, documentazione tecnica, e-mail aziendali) il rischio di memorization si estende ai dati riservati inclusi nel dataset di fine-tuning.

Il rischio di data leakage non si limita ai dati di training: riguarda anche i dati presenti nel contesto di una conversazione con un LLM.

Molti assistenti LLM integrati nei workflow aziendali ricevono nel prompt informazioni sensibili (dati di clienti, credenziali parziali, informazioni di business riservate) che potrebbero essere esposte attraverso l’output del modello se non sono implementati controlli adeguati sull’output stesso o che potrebbero essere usate per addestrare versioni future del modello se i provider non offrono garanzie sulla gestione dei dati inviati via API.

Strategie di mitigazione e sviluppo sicuro con assistenti IA

La risposta corretta ai rischi degli LLM nello sviluppo software non è il divieto – le organizzazioni che proibiscono l’uso degli LLM vedono i propri sviluppatori usarli comunque, ma in modo non governato e non monitorato – ma la strutturazione di un processo di sviluppo sicuro che integra gli LLM come strumenti con controlli adeguati.

L’obiettivo è sfruttare i vantaggi di produttività degli assistenti AI mantenendo lo stesso livello di assurance sulla sicurezza del codice che ci si aspetta dallo sviluppo tradizionale.

Validazione rigorosa e sanificazione del codice generato automaticamente

Il codice generato da un LLM deve essere trattato come qualsiasi altro codice di terze parti: non come codice scritto da un collega di fiducia che si assume abbia rispettato le best practice di sicurezza, ma come codice esterno che richiede verifica prima dell’integrazione.

Questa analogia è più che metaforica: i rischi introdotti dal codice generato da LLM (dipendenze da librerie problematiche, pattern insicuri, vulnerabilità sottili) sono strutturalmente simili al rischio cyber nella catena di fornitura software.

Il codice LLM è, in un certo senso, il fornitore più prolifico e meno controllato dell’ecosistema di sviluppo moderno.

La validazione del codice generato da LLM deve operare su tre livelli complementari.

Il primo è la revisione semantica da parte di uno sviluppatore con conoscenza del dominio di sicurezza: non una review superficiale che verifica la funzionalità, ma una verifica critica dei pattern di sicurezza, della gestione dell’input, della gestione degli errori e delle dipendenze introdotte.

Il secondo livello è l’analisi statica automatizzata (SAST): strumenti come Semgrep, SonarQube, Bandit (per Python) e CodeQL analizzano il codice alla ricerca di pattern noti di vulnerabilità e devono essere eseguiti su tutto il codice generato da LLM prima dell’integrazione nel repository.

Il terzo livello è la Software Composition Analysis (SCA): ogni dipendenza introdotta dal codice generato deve essere analizzata per vulnerabilità note, licenze problematiche e indicatori di rischio (età del pacchetto, numero di download, reputazione del maintainer).

Implementazione di test di sicurezza automatizzati nel ciclo di CI/CD

L’integrazione dei test di sicurezza nella pipeline CI/CD è il controllo che garantisce che il codice generato da LLM e tutto il codice in generale non raggiunga la produzione senza aver superato un set minimo di verifiche di sicurezza automatizzate.

In un contesto di sviluppo con LLM, questo è ancora più critico perché il volume di codice prodotto aumenta significativamente, rendendo impraticabile la sola revisione manuale come unico presidio di sicurezza.

La pipeline di sicurezza per il codice generato da LLM dovrebbe includere almeno: analisi statica (SAST) con regole specifiche per le vulnerabilità più frequenti nel codice LLM (injection, crittografia debole, hardcoded secrets), analisi della composizione software (SCA) per tutte le dipendenze introdotte, secret scanning per rilevare credenziali hardcoded (strumenti come GitGuardian, TruffleHog, GitHub Secret Scanning) e, per i componenti più critici, analisi dinamica (DAST) o fuzzing per rilevare vulnerabilità che non emergono dall’analisi statica.

Il blocco automatico del merge in caso di finding critici, non un semplice avviso, è il controllo che trasforma la pipeline di sicurezza da strumento di reporting a gate di qualità effettivo.

Ruolo della governance aziendale nell’adozione sicura dell’IA

La governance dell’uso degli LLM nello sviluppo software non è una questione che può essere delegata ai singoli team di sviluppo: richiede policy aziendali esplicite, processi di approvazione per l’adozione di nuovi strumenti AI e meccanismi di monitoraggio che rendano visibile come e dove gli LLM vengono utilizzati.

In assenza di governance, il risultato tipico è la proliferazione di strumenti AI non approvati, il cosiddetto «shadow AI», che introduce rischi non gestiti e non visibili alla funzione di sicurezza.

Una policy aziendale sull’uso degli LLM nello sviluppo software dovrebbe coprire almeno: quali strumenti sono approvati per quali task (assistenti AI per la generazione di codice non critico vs strumenti più controllati per codice che gestisce dati sensibili), quali dati possono essere inviati a provider LLM esterni vs quali richiedono l’uso di modelli interni, gli obblighi di revisione del codice generato prima dell’integrazione e le responsabilità in caso di incidente di sicurezza originato da codice generato da un LLM non approvato.

Definizione di policy per l’uso dei modelli e monitoraggio delle API

Il monitoraggio delle API degli LLM è un elemento di governance spesso trascurato ma fondamentale per la sicurezza operativa. Le chiamate API ai provider LLM lasciano tracce (log delle richieste, metadati sul volume e sulla frequenza delle chiamate, in alcuni casi il contenuto stesso delle richieste) che devono essere gestite con lo stesso rigore dei log di qualsiasi altro sistema critico.

Per le organizzazioni soggette a GDPR, la questione della protezione dei dati inviati ai provider LLM è particolarmente rilevante: ogni prompt che contiene dati personali è un trasferimento di dati a un responsabile del trattamento (il provider LLM) che deve essere regolamentato da un DPA conforme.

Le policy per l’uso dei modelli devono includere anche la gestione delle chiavi API: le chiavi di accesso ai provider LLM sono credenziali privilegiate che consentono di effettuare chiamate a costo del titolare e di accedere potenzialmente a dati inviati nelle conversazioni.

La rotazione regolare, l’uso di secrets manager (HashiCorp Vault, AWS Secrets Manager) invece di variabili d’ambiente, la limitazione dei permessi per ogni chiave al minimo necessario (principle of least privilege applicato alle API key) e il monitoraggio dell’utilizzo per rilevare anomalie (volume insolitamente elevato, chiamate da IP inattesi) sono controlli fondamentali che molte organizzazioni non hanno ancora implementato sistematicamente.

Impatto a lungo termine dei modelli LLM sulla gestione del debito tecnico

Il debito tecnico, ossia l’accumulo di scorciatoie, compromessi e decisioni architetturali subottimali che rallentano lo sviluppo futuro e aumentano il rischio operativo, ha una nuova dimensione nell’era degli LLM.

Il codice generato automaticamente tende a essere funzionalmente corretto ma architetturalmente superficiale: risolve il problema immediato senza considerare la manutenibilità nel tempo, la coerenza con i pattern architetturali esistenti, o le implicazioni di sicurezza a lungo termine.

Quando questo codice viene integrato su larga scala – e la produttività degli LLM lo rende possibile su scale senza precedenti – il risultato è un’accelerazione del debito tecnico che può compromettere la postura di sicurezza dell’intera base di codice nel medio termine.

Il debito tecnico di sicurezza generato dagli LLM si manifesta in modi specifici:

• frammentazione dei pattern di sicurezza (ogni generazione produce implementazioni leggermente diverse della stessa logica di autenticazione, rendendo difficile l’audit e la manutenzione uniforme);
• proliferazione di dipendenze (ogni sessione con un LLM può introdurre nuove librerie non presenti nel catalogo approvato);
• degradazione della comprensione del codice (gli sviluppatori che accettano codice generato senza comprenderlo appieno perdono la capacità di identificare e correggere le vulnerabilità in esso contenute).

Questo ultimo punto è forse il più preoccupante a lungo termine: la sicurezza del software dipende in ultima analisi dalla comprensione profonda del codice da parte degli sviluppatori che lo gestiscono, e gli LLM rischiano di erodere questa comprensione se usati come sostituto, anziché come complemento, del ragionamento critico.

La gestione del debito tecnico di sicurezza nell’era degli LLM richiede un approccio proattivo: audit periodici specificamente orientati al codice generato da AI per identificare pattern di vulnerabilità sistematici, metriche che traccino la percentuale di codice generato da LLM nella base di codice e la sua correlazione con i finding di sicurezza e programmi di formazione che mantengano le competenze di sicurezza degli sviluppatori anche nell’era dell’assistenza AI.

Gli LLM sono strumenti potenti che possono migliorare significativamente la sicurezza del software se usati correttamente, per esempio, per generare test di sicurezza, per identificare pattern vulnerabili nel codice esistente, per accelerare la remediation di vulnerabilità note. Ma richiedono una governance attiva per non diventare un acceleratore di debito tecnico e di rischio di sicurezza.