Riepilogo Tecnico: Le Sonde di Attivazione Rilevano Segnali di Sicurezza del Codice che l'Output del Modello Ignora

Definizione del Problema

Gli agenti di codifica IA (ad es., Claude Code, Cursor, OpenAI Codex) stanno sempre più scrivendo codice di produzione, con audit empirici che indicano che il 24–29% degli snippet Python e JavaScript generati dall'IA contiene debolezze di sicurezza. La revisione umana della sicurezza non può scalare per eguagliare il tasso di generazione del codice, rendendo necessaria una gestione automatizzata. Tuttavia, gli attuali controlli automatizzati sono insufficienti: gli analizzatori statici soffrono di alti tassi di falsi positivi e l'uso di prompt a Large Language Models (LLM) per ottenere verdetti di sicurezza binari non è robusto. Riscritture triviali del codice possono invertire i verdetti dell'LLM, e i modelli spesso emettono risposte "SÌ/NO" identiche sia per le coppie di codice vulnerabile che per quelle corrette, rendendo il loro output dichiarato inutile per distinguere il rischio.

Inoltre, gli agenti di codifica più utilizzati sono a pesi chiusi (closed-weight), impedendo ai team di implementazione di ispezionare i loro stati interni. I team possono invece implementare modelli a pesi aperti (open-weight) come revisori, ma il prompting standard di questi revisori fallisce nel rilevare vulnerabilità che gli stati nascosti del modello stesso potrebbero codificare.

Metodologia

L'autore indaga se le sonde lineari applicate alle attivazioni del residual stream di LL per il codice a pesi aperti possano recuperare segnali di sicurezza che gli output indotti da prompt del modello perdono.

Modelli e Dati

• Modelli Revisori: Sono stati valutati cinque LL per il codice a pesi aperti appartenenti a quattro famiglie di architetture: Qwen2.5-Coder (7B, 14B), DeepSeek-Coder (33B), Devstral-Small e Llama-3.1 (8B).
• Dati di Addestramento (SVEN-Python): Le sonde sono state addestrate su coppie di funzioni Python vulnerabili e corrette dal dataset SVEN, coprendo quattro specifiche Common Weakness Enumerations (CWE): 022, 078, 079 e 089.
• Dati di Valutazione (PATCHEVAL): Le sonde sono state testate zero-shot su 234 vulnerabilità Python reali e dichiarate (CVE) dal benchmark PATCHEVAL. Fondamentalmente, i CVE utilizzati per la valutazione contenevano tipi di CWE non visti durante l'addestramento (nessuna sovrapposizione con le quattro CWE di addestramento).
• Suddivisione dei Dati: Per prevenire la fuga di dati (data leakage), le suddivisioni sono state raggruppate per progetto/repository, garantendo che nessun codice di un determinato repository apparisse sia nell'addestramento che nella valutazione.

Fitting della Sonda

• Architettura: È stata applicata una singola sonda lineare per modello.
• Input: Le attivazioni sono state estratte dall'input della normalizzazione dei layer (layers[L].input_layernorm) utilizzando nnsight.
• Ottimizzazione: L'autore ha effettuato una ricerca (sweep) attraverso i layer, le strategie di pooling dei token (mean, max, last, sliding-window-max) e la forza della regolarizzazione L2. È stata selezionata la configurazione che massimizzava l'AUC del 5-fold GroupKFold.
• Task: La sonda impara a distinguere tra una funzione vulnerabile e la sua controparte corretta basandosi esclusivamente sulle attivazioni dello stato nascosto.

Metriche di Valutazione

• Paired Win-Rate (Tasso di Vittoria in Coppia): Per ogni CVE, la sonda valuta la funzione vulnerabile ($\hat{p}_{vul}$) e la funzione corretta ($\hat{p}_{fix}$). Il win-rate è la frazione di casi in cui $\hat{p}_{vul} > \hat{p}_{fix}$.
• Comparatori: La sonda è stata confrontata con l'output indotto da prompt dello stesso modello in tre condizioni:
  1. No-shot: Query diretta senza esempi.
  2. Few-shot: Query con esempi di tipi di debolezze non presenti nell'addestramento.
  3. Chain-of-Thought (CoT): Query che richiede un ragionamento passo dopo passo prima di un verdetto.
• Metodi di Lettura (Readout): I comparatori sono stati valutati sia tramite logit readout (probabilità YES/NO rinormalizzata) che tramite token readout (letterale stringa "yes"/"no").

Risultati Chiave

1. Le Sonde Rilevano Segnali che il Prompting Ignora

Sulle vulnerabilità reali e non viste (singole funzioni CVE), la sonda lineare ha classificato costantemente la funzione vulnerabile come superiore alla sua versione corretta, ottenendo un paired win-rate del 61–67% in tutti e cinque i modelli. Questa performance è statisticamente significativa ($p < 0.05$) e costantemente al di sopra della linea del caso (50%).

Al contrario, gli output indotti da prompt dei modelli hanno performato scarsamente:

• Logit Readout: Il win-rate della sonda è stato superiore al logit readout dei modelli indotti da prompt per ogni modello sotto ogni condizione di prompt. Tuttavia, mentre il vantaggio della sonda rispetto al no-shot prompting era significativo su tre dei cinque modelli e rispetto al few-shot prompting su quattro, il vantaggio rispetto al Chain-of-Thought (CoT) prompting letto dai logit era ristretto e statisticamente significativo solo per uno dei cinque modelli. Nonostante questo margine ridotto, il win-rate della sonda è rimasto superiore al CoT per ogni modello.
• Token Readout: Leggendo il verdetto testuale letterale, i modelli non sono riusciti a distinguere le coppie nel 72–97% dei casi, assegnando la stessa parola sia alla funzione vulnerabile che a quella corretta.

2. Generalizzazione a Tipi di Debolezza Non Visti

Le sonde, addestrate solo su quattro specifiche CWE, si sono generalizzate con successo a 234 CVE con tipi di debolezza completamente diversi. Ciò suggerisce che le sonde catturino un "segnale di sicurezza del codice" generalizzabile piuttosto che memorizzare pattern di vulnerabilità specifici.

3. Stato Interno vs. Output Dichiarato

Lo studio conferma un divario tra la rappresentazione interna di un modello e il testo generato. Mentre la risposta dichiarata dal modello (token) spesso collassa in un pareggio, la probabilità interna (logit) e la sonda di attivazione mantengono un segnale capace di classificare il rischio. La sonda "espone" efficacemento un segnale di sicurezza che il meccanismo di output del modello stesso scarta.

4. Performance In-Distribution

Sulla distribuzione di addestramento (SVEN-Python), le sonde hanno raggiunto un AUC di 0.77–0.85 e un'accuratezza di 0.72–0.77 a una soglia di 0.5, superando significativamente i modelli indotti da prompt (accuratezza ~0.50).

Significato e Rivendicazioni

L'articolo sostiene che le attivazioni del modello trasportano un segnale di sicurezza del codice che il prompting dello stesso modello perde.

• Revisione Scalabile: Le scoperte suggeriscono una via per controlli di sicurezza auto-ospitati in cui un modello a pesi aperti agisce come revisore. Leggendo gli stati nascosti di questo revisore tramite una sonda lineare, i team possono segnalare modifiche che meritano una revisione umana senza dover accedere agli interni dell'agente di codifica a pesi chiusi che ha generato il codice.
• Superiorità rispetto al Prompting: La sonda supera le strategie di no-shot e few-shot prompting dello stesso modello sulle vulnerabilità non viste. Sebbene la sonda superi anche il prompting Chain-of-Thought (CoT) in termini di win-rate in tutti i modelli, il vantaggio rispetto al CoT è ridotto e non sempre statisticamente significativo. Il divario netto rimane comunque rispetto al no-shot e al few-shot prompting.
• Modesto ma Robusto: L'autore caratterizza l'effetto come "modesto" (win-rate nei bassi 60) ma costante attraverso architetture e tipi di debolezza. Afferma esplicitamente che integrare la sonda in un hook post-scrittura di un agente di codifica e calibrare soglie assolute sono passi necessari per il futuro deployment.

Il lavoro estende la ricerca precedente sulle sonde lineari per la sicurezza e il rilevamento delle vulnerabilità dimostrando la trasferibilità a tipi di debolezza non visti e CVE reali, e confrontando direttamente le capacità di ragionamento indotte da prompt del modello contro le sue stesse capacità.