Extracting Recurring Vulnerabilities from Black-Box LLM-Generated Software

Questo studio introduce FSTab, un metodo per identificare e valutare le vulnerabilità ricorrenti nei software generati da LLM tramite un attacco in black-box che prevede le falle nel backend basandosi sulle funzionalità frontend, rivelando così rischi di sicurezza significativi e trasferibili tra diversi domini applicativi.

L'essenziale

Immagina di aver appena assunto un architetto molto intelligente, ma un po' "robotico", per costruire la tua casa. Questo architetto è un'Intelligenza Artificiale (LLM) specializzata nel scrivere codice per software. È veloce, creativo e costruisce case bellissime in pochi secondi.

Tuttavia, c'è un problema: questo architetto ha delle abitudini fisse. Se gli chiedi di costruire un cancello, lo costruirà sempre nello stesso modo, anche se quel modo ha un difetto nascosto (ad esempio, la serratura è troppo facile da forzare). Se gli chiedi di costruire una finestra, userà sempre lo stesso tipo di vetro fragile.

Il problema è che tu, come proprietario di casa (l'utente o l'attaccante), vedi solo la facciata della casa (il sito web, i pulsanti, le finestre). Non puoi vedere le fondamenta o le tubature nascoste dietro i muri (il codice backend), perché sono segrete.

Ecco di cosa parla questo studio, spiegato in modo semplice:

1. Il Concetto: "L'Impronta Digitale dei Difetti"

Gli autori hanno scoperto che ogni modello di intelligenza artificiale ha un "impronta digitale" unica nei suoi errori.
Proprio come un muratore che usa sempre lo stesso tipo di malta sbagliata, ogni AI tende a ripetere gli stessi errori di sicurezza ogni volta che crea una funzione specifica (come un login o un upload di file).

• L'analogia: Immagina che ogni AI sia un cuoco. Se il "Cuoco A" fa sempre la pasta con troppa sale, e il "Cuoco B" la fa sempre con troppa acqua, basta assaggiare il piatto per capire chi l'ha cucinato, anche senza vedere la ricetta. Allo stesso modo, basta guardare cosa fa il software (es. "c'è un pulsante per resettare la password") per sapere quali errori di sicurezza sono nascosti dietro, senza dover leggere il codice.

2. La Soluzione: La "Tabella dei Segreti" (FSTab)

Gli autori hanno creato uno strumento chiamato FSTab (Feature–Security Table).
Pensa a FSTab come a una mappa del tesoro o a un dizionario dei difetti.

• Come funziona:
  1. Hanno fatto costruire all'AI migliaia di siti web e programmi.
  2. Hanno analizzato questi programmi per vedere quali "punti deboli" (vulnerabilità) si nascondevano dietro ogni "pulsante" o "funzione" visibile.
  3. Hanno creato una tabella che dice: "Se vedi il pulsante 'Login', e sai che è stato fatto dal 'Cuoco A' (es. GPT-5), allora c'è il 90% di probabilità che dietro ci sia una serratura difettosa."

3. L'Attacco: "Vedere l'Invisibile"

Il punto rivoluzionario è che questo attacco funziona in scatola nera (Black-Box).
Non serve essere hacker esperti che sanno leggere il codice sorgente. Basta essere un osservatore attento.

• La scena: Un hacker arriva al tuo sito. Non ha le chiavi per entrare nel server.
• L'azione: Guarda la pagina e dice: "Ah, vedo che c'è un modulo per 'Caricare un documento'. So che questo sito è stato fatto dal modello 'Claude'. Secondo la mia tabella FSTab, quando Claude fa questo, lascia sempre una porta aperta."
• Il risultato: L'hacker può predire esattamente dove cercare il buco di sicurezza e attaccarlo, anche senza aver mai visto il codice interno.

4. La Scoperta Sorprendente: "L'Errore è Universale"

Lo studio ha scoperto che questi errori sono ostinati.

• Non dipendono dal compito: Che tu chieda all'AI di creare un blog di cucina o un gestionale bancario, se l'AI è la stessa, farà gli stessi errori di sicurezza.
• Non dipendono dalle parole: Se cambi le parole della richiesta (es. "Fammi un login" invece di "Crea un sistema di autenticazione"), l'AI fa comunque lo stesso errore. È come se l'AI avesse un "muscolo" difettoso che si attiva sempre allo stesso modo.

Perché è importante?

Fino a oggi, pensavamo che la sicurezza fosse un problema che si risolveva controllando il codice dopo averlo scritto. Questo studio ci dice: "No, il problema è l'architetto stesso."

Se sai che un certo modello di AI tende a costruire serrature deboli ogni volta che gli chiedi di fare un login, non devi aspettare di finire la casa per scoprire il problema. Puoi dirlo subito, prima ancora di iniziare a costruire, basandoti solo su cosa vedi dalla strada.

In sintesi

Questo paper ci avverte che l'uso massiccio dell'AI per scrivere software sta creando un nuovo tipo di rischio: software prevedibilmente difettoso.
Gli autori ci danno un "binocolo" (FSTab) che permette di vedere i pericoli nascosti guardando solo la superficie, trasformando la sicurezza informatica da un'arte oscura a una scienza basata su pattern riconoscibili.

Il messaggio finale: Quando usi l'AI per costruire il tuo software, non fidarti ciecamente. Ricorda che ogni "cuoco" AI ha i suoi vizi, e a volte quei vizi possono costare cari.

Sommario tecnico

1. Il Problema

L'uso dei Modelli Linguistici (LLM) per la generazione di codice è in rapida espansione, con una stima che circa il 30% delle nuove funzioni Python in alcune regioni sia ora generata dall'IA. Tuttavia, esiste un divario critico tra le capacità funzionali e la sicurezza: il codice generato dagli LLM contiene spesso vulnerabilità ricorrenti.

Il problema centrale identificato dagli autori è che gli LLM, a causa del loro campionamento probabilistico e della tendenza a riutilizzare modelli canonici per funzionalità comuni (es. login, upload file), generano vulnerabilità prevedibili e ripetitive. Queste vulnerabilità non sono casuali, ma formano "impronte digitali" specifiche del modello.
La sfida attuale è che le difese esistenti (analisi statica, benchmark) operano spesso a posteriori su singoli frammenti di codice, senza modellare le regolarità trasversali tra programmi diversi. Questo lascia un "punto cieco": non è possibile prevedere le vulnerabilità nascoste nel backend di un software basandosi solo sulle funzionalità osservabili nel frontend, specialmente in scenari black-box (dove non si ha accesso al codice sorgente).

2. Metodologia: FSTab (Feature–Security Table)

Gli autori introducono FSTab, un framework che trasforma le funzionalità osservabili del frontend in predittori di vulnerabilità nel backend. Il sistema si basa sull'ipotesi che un modello LLM specifico associ sistematicamente certe funzionalità frontend a specifiche scelte di design insicure nel backend.

Il processo si articola in tre fasi principali:

1. Costruzione della Tabella (Training):

   • Vengono generati grandi corpus di applicazioni utilizzando un LLM target.
   • Il codice viene analizzato con strumenti di analisi statica (CodeQL, Semgrep) per identificare le vulnerabilità reali (ground truth).
   • Vengono estratte le funzionalità frontend osservabili (es. "login con password", "upload file") utilizzando parser AST e regex.
   • Viene calcolato un punteggio di associazione tra una funzionalità $f$ e una vulnerabilità $r$ utilizzando la Mutua Informazione Puntuale (PMI). Questo permette di distinguere le vulnerabilità generiche da quelle specifiche del modello.
   • Viene applicato un algoritmo di selezione "greedy" con una penalità per la diversità, per evitare che le stesse regole di sicurezza vengano mappate su tutte le funzionalità, garantendo così una tabella discriminativa.

2. Attacco Black-Box (Inference):

   • Un attaccante, conoscendo l'identità del modello LLM usato per generare il software e osservando le funzionalità del frontend (senza vedere il codice sorgente), interroga la tabella FSTab specifica per quel modello.
   • Il sistema restituisce una lista prioritizzata di vulnerabilità backend probabili.

3. Framework di Valutazione:

   • Gli autori definiscono quattro metriche per quantificare la persistenza delle vulnerabilità:
     • FVR (Feature Vulnerability Recurrence): Quanto spesso una specifica funzionalità genera la stessa vulnerabilità.
     • RVP (Rephrasing Vulnerability Persistence): Quanto le vulnerabilità persistono nonostante le riformulazioni semantiche del prompt.
     • DVR (Domain Vulnerability Recurrence): La ricorrenza delle vulnerabilità all'interno dello stesso dominio applicativo.
     • CDT (Cross-Domain Transfer): La capacità di predire vulnerabilità in un dominio sconosciuto basandosi su dati di altri domini.

3. Contributi Chiave

1. Attacco Black-Box Universale: Dimostrazione che è possibile inferire vulnerabilità backend nascoste osservando solo le funzionalità frontend, sfruttando le "impronte digitali" di generazione del modello.
2. Framework di Valutazione Centrato sul Modello: Introduzione di metriche (FVR, RVP, DVR, CDT) per misurare quanto un modello sia "rigido" nel riprodurre errori di sicurezza, indipendentemente dal prompt o dal dominio.
3. Caratterizzazione Empirica: Analisi dettagliata su sei modelli LLM all'avanguardia (tra cui GPT-5.2, Claude-4.5 Opus, Gemini-3 Pro) su cinque domini applicativi diversi, rivelando pattern di vulnerabilità specifici per modello.

4. Risultati Sperimentali

Gli esperimenti sono stati condotti su 1050 programmi generati su dataset come WebGenBench ed E2EDev.

• Successo dell'Attacco: FSTab ha dimostrato un'efficacia elevata. Su alcuni modelli (es. Claude-4.5 Opus), l'attacco ha raggiunto un tasso di successo (ASR) fino al 94% e una copertura delle vulnerabilità (ACR) del 93% anche quando il dominio target era stato escluso dalla fase di costruzione della tabella.
• Trasferibilità Cross-Dominio: I risultati mostrano che le vulnerabilità sono intrinseche al modello e non specifiche del dominio. Il punteggio CDT è spesso superiore al DVR, indicando che un attaccante può profilare un modello su un tipo di applicazione (es. blog) e compromettere con successo un altro tipo (es. strumenti interni).
• Persistenza delle Vulnerabilità: Modelli come Composer e GPT-5.2 mostrano un'alta persistenza (RVP ~50%), il che significa che le loro vulnerabilità sono robuste anche quando il prompt viene riformulato. Al contrario, modelli come Grok mostrano una persistenza inferiore, suggerendo una maggiore variabilità stocastica.
• Impronte Digitali: Ogni modello ha mostrato pattern di vulnerabilità unici. Ad esempio, certi modelli tendono sistematicamente a introdurre SQL Injection o XSS in specifiche funzionalità come "Login" o "Upload File".

5. Significato e Implicazioni

Questo lavoro espone una superficie di attacco precedentemente sottovalutata nello sviluppo software basato su LLM:

• Rischio Sistemico: La sicurezza non dipende solo dalla correttezza del singolo prompt, ma da bias strutturali nel modello che generano errori prevedibili su larga scala.
• Nuova Minaccia: Gli attaccanti possono mappare le vulnerabilità di un intero ecosistema software semplicemente conoscendo il modello LLM utilizzato e osservando l'interfaccia utente, senza bisogno di reverse engineering del codice.
• Implicazioni Difensive: Il paper suggerisce la necessità di:
  • Valutazioni di sicurezza basate sul modello (model-centric) piuttosto che sul singolo output.
  • Test di regressione specifici per le funzionalità ad alto rischio (feature-conditioned).
  • Mitigazioni durante la fase di decoding o training per ridurre la rigidità dei template insicuri.

In sintesi, il paper dimostra che l'uso degli LLM per la generazione di codice introduce un rischio di sicurezza sistematico e prevedibile, trasformando le funzionalità visibili dell'interfaccia in segnali affidabili per prevedere e sfruttare le debolezze nascoste nel backend.