Sintesi Tecnica: Uno Studio Empirico sulla Calibrazione della Sicurezza nei Large Language Models per il Codice

1. Definizione del Problema

I Large Language Models (LLM) sono sempre più integrati nei flussi di lavoro dello sviluppo software per compiti quali la generazione di codice e la correzione di bug. Tuttavia, il loro dispiegamento in contesti critici per la sicurezza solleva una domanda fondamentale: i modelli sanno effettivamente quando il codice generato è insicuro?

Mentre i benchmark esistenti (ad es., HumanEval, MBPP, SWE-Bench) valutano la correttezza funzionale, essi ignorano ampiamente le proprietà di sicurezza. I recenti benchmark orientati alla sicurezza valutano se il codice contenga vulnerabilità, ma non riescono a misurare se i modelli siano in grado di auto-valutare la sicurezza dei propri output. Questa lacuna porta al fenomeno della Falsa Fiducia (False Trust), in cui i modelli assegnano un'alta confidenza al codice vulnerabile. Gli sviluppatori, facendo affidamento su questi segnali di confidenza, possono accettare output insicuri senza scetticismo, propagando vulnerabilità nei sistemi di produzione.

I lavori precedenti non hanno misurato sistematicamente la calibrazione della sicurezza — ovvero l'allineamento tra la confidenza dichiarata dal modello riguardo alla sicurezza del proprio output e lo stato di sicurezza effettivo dell'output stesso. Inoltre, rimane ignoto se i pattern di calibrazione osservati in programmi isolati e autosufficienti si generalizzino a contesti di repository realistici e multi-file, o se i segnali di calibrazione possano guidare efficacemente la riparazione automatizzata delle vulnerabilità.

2. Metodologia

Gli autori presentano il primo studio empirico su larga scala della calibrazione della sicurezza, valutando tre modelli allo stato dell'arte: GPT-4o-mini, Gemini-2.0-Flash e Qwen3-Coder-Next. Lo studio impiega una valutazione multi-stadio attraverso due benchmark complementari e quattro domande di ricerca (RQ).

Dataset e Contesti

• Programmi Autosufficienti (RQ1): Utilizza il benchmark SALLM, composto da 100 task Python critici per la sicurezza. Ogni task fornisce un singolo prompt con input, output attesi e requisiti di sicurezza, isolati da dipendenze esterne.
• Contesti a Livello di Repository (RQ2): Utilizza il benchmark AICGSecEval, che presenta 125 prompt in quattro linguaggi (C, Java, PHP, Python) e 29 CWE. Questi task richiedono la generazione di patch all'interno di repository multi-file esistenti, coinvolgendo dipendenze cross-file, configurazioni di build e API esterne.

Setup Sperimentale

• Modelli e Parametri: Ogni modello è stato testato attraverso sei impostazioni di temperatura (da 0.0 a 1.0), generando 20 campioni per task.
• Stima della Confidenza: Sono stati confrontati quattro metodi:
  1. Aggregazione della probabilità dei token: Accesso diretto alle probabilità dei logit (per GPT/Gemini).
  2. Confidenza verbalizzata: Prompting del modello per produrre un JSON con un punteggio di confidenza (0–1) e una spiegazione.
  3. Consistenza basata sul campionamento: Stima della confidenza come frazione di 20 campioni che superano la verifica.
  4. Prompting di auto-consistenza: Ragionamento Chain-of-Thought (CoT) prima di riportare la confidenza.
• Verifica: Il codice è stato eseguito in container Docker isolati. Le etichette di sicurezza sono state definite come $y_{sec} = y_{func} \land \neg y_{vuln}$, il che significa che il codice deve superare tutti i test funzionali e fallire tutti i test di exploit delle vulnerabilità per essere considerato sicuro.
• Metriche: Errore di Calibrazione Attesa (ECE), Brier Score, Gap di Sovra-confidenza e tasso di Falsa Fiducia (FT) (predizioni ad alta confidenza che sono insicure).

Strategie di Riparazione e Mitigazione (RQ3 & RQ4)

• Riparazione Guidata dalla Calibrazione: Un sistema a ciclo chiuso ha filtrato i campioni con bassa confidenza calibrata ($p_{sec} < 0.5$) per una riparazione iterativa. Gli esiti sono stati stratificati per tipo di vulnerabilità: Sostituzione del Sink (SR) (che richiede modifiche alle API) e Imposizione di Vincoli (CE) (che richiede logica di validazione).
• Esperimenti di Mitigazione:
  1. Execution Gating (Filtraggio tramite esecuzione): Filtraggio del codice funzionalmente errato prima di elicitare la confidenza di sicurezza.
  2. Riparazione con Autorizzazione alla Rottura (Authorized-Breaking Repair): Autorizzazione esplicita dei modelli a rompere la compatibilità all'indietro (ad es., sostituendo pickle con json) per correggere le vulnerabilità SR.
  3. Few-Shot Prompting: Fornitura di esempi di codice sicuro.
  4. Few-Shot + CoT: Aggiunta di passaggi di ragionamento agli esempi few-shot.

3. Risultati Chiave

RQ1: Calibrazione nella Generazione Autosufficiente

• Sovra-confidenza Sistematica: Tutti i modelli mostrano una grave sovra-confidenza. GPT-4o-mini e Qwen3-Coder-Next mostrano un alto ECE (0.46–0.48 e 0.41–0.42, rispettivamente), mentre Gemini-2.0-Flash si comporta meglio ma rimane sovra-confermato (ECE 0.25–0.26).
• Falsa Fiducia: Con una soglia di confidenza di 0.8, i tassi di Falsa Fiducia sono allarmanti (ad es., 33.5% per GPT-4o-mini, 40.3% per Qwen3-Coder-Next), indicando che gli output ad alta confidenza sono frequentemente insicuri.
• Calibrazione Funzionale vs. Sicurezza: Controintuitivamente, la calibrazione funzionale è costantemente peggiore della calibrazione della sicurezza ($\Delta ECE < 0$). I modelli sono più mal calibrati riguardo alla correttezza funzionale rispetto alla sicurezza. Ciò suggerisce che i modelli stimano gli esiti di sicurezza in modo più affidabile rispetto a quelli funzionali, forse perché la correttezza funzionale dipende da comportamenti di esecuzione complessi e nascosti.
• Metodi di Confidenza: L'aggregazione della probabilità dei token produce una scarsa calibrazione (ECE $\approx$ 0.80). La consistenza basata sul campionamento mostra un ECE vicino allo zero ma manca di discriminazione per singolo campione. La confidenza verbalizzata è il segnale più pratico per l'analisi a valle.

RQ2: Degradazione a Livello di Repository

• Collasso della Calibrazione: Il passaggio da task autosufficienti a contesti a livello di repository causa un significativo deterioramento della calibrazione. L'ECE aumenta approssimativamente di tre o quattro volte (ad es., l'ECE di GPT-4o-mini sale da 0.41 a 0.70).
• Impennata della Falsa Fiducia: I tassi di Falsa Fiducia balzano da ~17% nei task autosufficienti a >80% nei contesti di repository.
• Decomposizione: Il degrado è guidato da due fattori: fragilità della build (codice che fallisce la compilazione/esecuzione) e complessità cross-file. Sebbene la fragilità della build rappresenti una grande porzione dell'errore (fino all'82% per GPT), la reale complessità cross-file rimane un fattio significativo anche nei patch che vengono compilati con successo.

RQ3: Riparazione Guidata dalla Calibrazione

• Efficacia Limitata: L'uso di segnali di calibrazione per guidare la riparazione produce miglioramenti minimi nella sicurezza e spesso degrada la funzionalità.
• Barriere Strutturali: Le vulnerabilità di Sostituzione del Sink (SR) (che richiedono lo scambio di API) hanno un tasso di successo della riparazione dello 0% in tutti i modelli. I modelli non riescono a sostituire le API insicure, invece preservano la vulnerabilità o introducono correzioni superficiali.
• Regressioni Funzionali: I tentativi di riparazione spesso rompono la correttezza funzionale (tassi di rottura >60%), portando a una diminuzione complessiva del tasso di sicurezza. La calibrazione agisce come un segnale di stratificazione del rischio ma non può guidare una riparazione automatizzata efficace per le vulnerabilità strutturali.

RQ4: Strategie di Mitigazione

• Execution Gating: La mitigazione più efficace. Filtrare il codice funzionalmente errato prima di chiedere la confidenza di sicurezza riduce l'ECE del 31–39% in tutti i modelli. Tuttavia, ciò comporta un alto costo in termini di scarto del 46–86% dei campioni.
• Riparazione con Autorizzazione alla Rottura: L'autorizzazione esplicita ai cambiamenti delle API migliora la rimozione delle vulnerabilità per GPT e Gemini (35–42%), ma comporta comunque un alto tasso di rottura funzionale e un basso successo rigoroso.
• Tecniche di Prompting: Il prompting few-shot rimuove circa il 61–65% delle vulnerabilità ma raramente supera la valutazione rigorosa a causa di mismatch strutturali di integrazione. L'aggiunta del ragionamento Chain-of-Thought (CoT) degrada la calibrazione e riduce il successo rigoroso allo 0%.

4. Contributi Chiave

1. Primo Studio su Larga Scala: La prima investigazione empirica della calibrazione della sicurezza nei codici generati da LLM, che copre 36.000 campioni su tre modelli, sei temperature e due distinti contesti di sviluppo.
2. Analisi della Degradazione della Calibrazione: Quantificazione della severa penalità di calibrazione subita passando da funzioni isolate a contesti realistici a livello di repository, evidenziando i rischi delle dipendenze cross-file.
3. Limitazioni della Riparazione: Dimostrazione che la riparazione guidata dalla calibrazione è inaffidabile, in particolare per le vulnerabilità di Sostituzione del Sink, a causa di una "barriera di rigidità" dove i modelli non riescono a eseguire trasformazioni strutturali necessarie.
4. Valutazione della Mitigazione: Valutazione sistematica degli interventi architettonici (execution gating) e a livello di prompt, identificando l'execution gating come la strategia più efficace per ridurre la Falsa Fiducia, sebbene con alti costi di rifiuto.

5. Significato e Rivendicazioni

L'articolo sostiene che la calibrazione, e non solo l'accuratezza, debba essere un criterio di valutazione centrale per gli LLM in contesti critici per la sicurezza. I risultati sfidano l'assunto che "la sicurezza sia più difficile" per gli LLM; invece, lo studio rivela che la calibrazione funzionale è peggiore della calibrazione della sicurezza, suggerendo che la mal calibrazione derivi in gran parte da vincoli di esecuzione nascosti (fragilità dell'esecuzione) piuttosto che da una mancanza di conoscenza della sicurezza.

Gli autori affermano che:

• La confidenza auto-riportata è inaffidabile: Gli output ad alta confidenza sono frequentemente insicuri, creando un rischio sistemico di Falsa Fiducia.
• Il contesto conta: I benchmark basati su programmi autosufficienti sottostimano significativamente i rischi di deployment, poiché la calibrazione degrada drasticamente nei contesti a livello di repository.
• La riparazione non è una soluzione magica: I segnali di calibrazione possono dare priorità ai campioni per la revisione umana ma non possono attualmente guidare una riparazione automatizzata affidabile per le vulnerabilità strutturali.
• Guida per i Professionisti: La valutazione della sicurezza dovrebbe avvenire solo dopo i test funzionali (execution gating), e i segnali di confidenza per la sicurezza e la funzionalità dovrebbero essere elicitati separatamente per evitare la contaminazione da incertezza di esecuzione.

Lo studio conclude che, sebbene gli LLM mostrino una certa capacità di auto-valutazione della sicurezza, la loro sovra-confidenza e l'incapacità di eseguire riparazioni strutturali rendono necessaria la supervisione umana, in particolare in ambienti di sviluppo complessi e multi-file.