Sintesi Tecnica: SPARK – Priming della Conoscenza sulla Sicurezza e Attivazione della Conoscenza Guidata dalla Rappresentazione

1. Definizione del Problema

I Large Language Models (LLM) generano regolarmente codice contenente vulnerabilità di sicurezza sfruttabili, anche quando vengono esplicitamente istruiti per non farlo. Sebbene i moderni LLM siano pre-addestrati su corpora ricchi di avvisi di sicurezza, database di vulnerabilità (es. CWE, CVE) e documentazione per sviluppatori, essi spesso non riescono ad applicare questa conoscenza durante la generazione del codice.

Il paper sostiene che la causa principale della generazione insicura non sia un deficit di conoscenza, ma un problema di dormienza della conoscenza. Senza un segnale esplicito e mirato, la pressione statistica a riprodurre i pattern comuni (spesso insicuri) della distribuzione di addestramento sopprime le rappresentazioni latenti relative alla sicurezza del modello. I meccanismi di difesa esistenti tentano di rimediare tramite:

• Fine-tuning: Il ri-addestramento dei parametri del modello è computazionalmente costoso, rischia il "catastrophic forgetting" (oblio catastrofico) e richiede pipeline specifiche per ogni backbone.
• Retrieval-Augmented Generation (RAG): L'iniezione di grandi quantità di esempi di codice esterni nei prompt introduce ridondanza nel contesto e un significativo overhead di inferenza.

Gli autori pongono il collo di bottiglia nell'attivazione al momento dell'inferenza, non nell'assenza di conoscenza, rendendo necessario un metodo che attivi le rappresentazioni interne esistenti senza modificare i pesi del modello o inondare il contesto con dati ridondanti.

2. Metodologia: SPARK

SPARK (Security Knowledge Priming And Representation-guided Knowledge Activation) è un framework di inferenza training-free e model-agnostic progettato per attivare la conoscenza latente sulla sicurezza. Esso consiste in due componenti ortogonali:

Componente I: Attivazione della Conoscenza sulla Sicurezza (Livello Prompt)

Questa componente opera recuperando e appendendo un segnale strutturato al prompt di input prima dell'inizio della generazione.

• Meccanismo: Invece di recuperare interi esempi di codice (come nel RAG), SPARK recupera le voci più rilevanti dal catalogo Common Weakness Enumeration (CWE) in base al compito di codifica.
• Processo:
  1. La domanda di codifica viene codificata utilizzando un sentence-transformer (es. all-MiniLM-L6-v2).
  2. Viene calcolata la similarità del coseno rispetto a un indice pre-codificato di voci CWE.
  3. Le top-$K$ voci vengono formattate in un blocco conciso contenente l'ID CWE, una descrizione del rischio troncata e i passaggi di mitigazione.
  4. Questo blocco viene aggiunto al prompt come suffisso, assicurando che sia l'ultima informazione elaborata prima della generazione dei token.
• Obiettivo: Nominare esplicitamente la classe di vulnerabilità rilevante, agendo come un "trigger" per far emergere le esistenti rappresentazioni di sicurezza del modello senza aggiungere esempi di codice esterni.

Componente II: Decoding Vincolato alla Sicurezza (Livello Logit)

Questa componente impone un bias continuo verso la scelta di token sicuri durante il processo di decoding autoregressivo.

• Meccanismo: Utilizza un vettore di direzione sicura ($\delta$) nello spazio delle rappresentazioni del modello, definito come la differenza unitaria tra gli stati nascosti medi del codice sicuro ($\bar{h}^+$) e del codice insicuro ($\bar{h}^-$).
• Precomputazione Offline:
  1. Un piccolo dataset di coppie di codice sicuro/insicuro viene utilizzato per calcolare $\bar{h}^+$ e $\bar{h}^-$.
  2. La direzione sicura $\delta = (\bar{h}^+ - \bar{h}^-) / \|\bar{h}^+ - \bar{h}^-\|$ viene calcolata.
  3. Questo vettore viene proiettato attraverso l'head del linguaggio ($W_{lm}$) per produrre un bias di sicurezza dei token precomputato: $b = W_{lm} \cdot \delta$.
• Inferenza: Ad ogni step di decoding $t$, il bias $b$ viene aggiunto ai logit grezzi: $\tilde{\ell}_t = \ell_t + b$.
• Costo: Questa intervento richiede solo un'addizione vettoriale per token e comporta un overhead di runtime trascurabile.

Integrazione

Le due componenti sono composibili. La Componente I stabilisce un contesto rilevante per la sicurezza a livello di prompt, mentre la Componente II rinforza il vincolo ad ogni successivo step di decoding. La Componente I funziona da sola in un ambiente black-box (accesso API), mentre la Componente II richiede l'accesso white-box ai logit.

3. Contributi Chiave

1. Valutazione Estesa: Il paper estende le valutazioni di sicurezza ai sistemi commerciali allo stato dell'arte (famiglie GPT, Claude, DeepSeek), che erano precedentemente meno esaminati riguardo al comportamento di sicurezza nonostante l'alta capacità.
2. Nuova Prospettiva sull'Attivazione: Propone che la conoscenza della sicurezza sia già codificata nei modelli pre-addestrati e possa essere attivata tramite segnali leggeri al momento dell'inferenza piuttosto che tramite l'iniezione di conoscenza esterna o la modifica dei pesi. Gli autori verificano questo mostrando che il segnale del prompt sposta la rappresentazione interna del modello verso la "direzione sicura".
3. Studio Empirico Completo: Lo studio abbraccia 9 modelli open-source (inclusa l'analisi di scaling su varianti più grandi), 7 modelli commerciali e 3 linguaggi di programmazione (C++, Java, Python), confrontando SPARK con 7 baseline (fine-tuning, retrieval-augmented e metodi di co-decoding).

4. Risultati Sperimentali

Performance di Sicurezza

• Baseline Training-Free: SPARK raggiunge un Safe Code Rate medio del 63.8% tra i modelli open-source, superando significativamente la baseline del solo prompt (30.3%) e i metodi basati sul retrieval (RESCUE: 48.9%, CodeGuarder: 54.1%). Eguaglia o supera le migliori baseline di fine-tuning in molti contesti senza alcun aggiornamento dei parametri.
• Modelli Commerciali Black-Box: La Componente I da sola ha migliorato i tassi di codice sicuro per i modelli commerciali di frontiera (es. Claude, GPT-5.5, DeepSeek) fino al 37.8% in media in un ambiente totalmente black-box, dimostrando che anche i modelli di alto livello falliscono nell'attivare la conoscenza della sicurezza senza specifici segnali.
• Sinergia con il Fine-Tuning: Quando combinata con il fine-tuning (SPARK+), il metodo raggiunge un safe code rate medio dell'85.8%, ottenendo i risultati migliori o pari ai migliori in 11 dei 18 setting modello-linguaggio. Ripara efficacemente le "regressioni" dove il solo fine-tuning falliva in specifici linguaggi.

Preservazione dell'Utilità

• HumanEval: SPARK preserva la correttezza funzionale (pass@1) sul benchmark HumanEval. Per la maggior parte dei modelli, il cambiamento è trascurabile (+0.1% in media). A differenza dei metodi basati sul retrieval, che spesso degradano l'utilità affollando il contesto con esempi, i segnali concisi di SPARK non compromettono la capacità del modello di risolvere il compito di codifica primario.
• Confronto: I metodi di fine-tuning (es. SVEN, LoRA) hanno mostrato cali di utilità più grandi e variabili rispetto a SPARK.

Ablation e Analisi

• Contributo delle Componenti: La Componente I (segnale CWE) è il driver principale del miglioramento, portando CodeLlama-7B dal 2.1% al 71.1% di safe code su C++. La Componente II fornisce guadagni costanti ma modesti quando accoppiata alla Componente I.
• Shift della Rappresentazione: Il probing degli stati nascosti del modello conferma che il segnale CWE sposta la rappresentazione verso il vettore di direzione sicura $\delta$, validando l'ipotesi di "attivazione".
• Profondità di Retrieval: È stata trovata una profondità di retrieval ottimale di $K \in \{3, 5\}$ voci CWE; aumentare ulteriormente $K$ porta a diluizione dell'attenzione e diminuzione delle performance di sicurezza.

5. Significato e Rivendicazioni

Il paper sostiene che la generazione di codice insicuro sia fondamentalmente un problema di attivazione piuttosto che una mancanza di conoscenza. SPARK dimostra che:

• I modelli pre-addestrati possiedono una sostanziale conoscenza latente della sicurezza che è soppressa dai default statistici.
• Questa conoscenza può essere sbloccata tramite interventi leggeri e training-free (segnali strutturati e bias dei logit) che sono computazionalmente efficienti e model-agnostic.
• SPARK offre un'alternativa robusta al pesante fine-tuning o al retrieval ricco di contesto, fornendo un "pavimento di sicurezza" che compensa i bias distribuzionali nei modelli fine-tuned e attiva la conoscenza dormiente nelle API commerciali.

Gli autori concludono che SPARK sostituisce la necessità di risorse esterne di sicurezza al momento dell'inferenza, sfruttando la conoscenza del pre-addestramento del modello stesso, che rappresenta la più grande risorsa di sicurezza disponibile.