The Security Budget of Code LLMs: An Information-Theoretic Capacity-Security Bound

Sintesi Tecnica: Il Budget di Sicurezza dei Code LLM

Problema
Gli assistenti di programmazione basati su IA si affidano sempre più ai prompt in linguaggio naturale come interfaccia primaria per lo sviluppo software. Questo cambiamento introduce una vulnerabilità critica: piccole perturbazioni a un prompt (ad esempio, sostituzione di sinonimi, rinomina di identificatori o iniezione di commenti) possono alterare il codice generato lasciando al contempo l'intento dell'utente parzialmente riconoscibile. Le valutazioni esistenti si basano spesso sui tassi di esecuzione (pass@1) prima e dopo la perturbazione. Tuttavia, gli autori sostengono che ciò sia insufficiente per gli assistenti interattivi, poiché non riesce a distinguere tra un modello che ha perso tutta l'informazione del task (rendendo priva di senso la "robustezza") e uno che conserva abbastanza informazioni da essere riconoscibile ma ne sposta l'implementazione. Esiste la necessità di una visione a "livello di budget" che separi l'informazione del task, la fuga di informazioni dal prompt (prompt leakage) e la stabilità della generazione per comprendere i compromessi tra capacità funzionale e sicurezza sotto perturbazione.

Metodologia
Il documento formalizza questo compromesso utilizzando la teoria dell'informazione, definendo due quantità chiave per un modello di codice LLM $\pi$:

1. Capacità ($Cap$): L'informazione mutua tra la soluzione canonica $c^*$ e la generazione del modello $c_\pi$, denotata come $I(c^*; c_\pi)$. Questa misura quanta parte del task il modello cattura.
2. Sicurezza ($Sec$): L'informazione mutua tra la generazione sotto il prompt originale $p$ ($c_\pi$) e la generazione sotto un prompt perturbato avversariamente $\tilde{p}$ ($\tilde{c}_\pi$), denotata come $I(c_\pi; \tilde{c}_\pi)$. Questa funge da "canale di ritenzione della perturbazione", misurando l'informazione condivisa tra le output pulite e quelle perturbate.

Framework Teorico
Il contributo teorico centrale è il Teorema 1, che stabilisce un limite superiore sulla somma di queste due quantità:
$$Cap + Sec \leq H(c^*) + I(p; \tilde{p})$$
Qui, $H(c^*)$ è l'entropia della soluzione canonica (entropia del task) e $I(p; \tilde{p})$ è l'informazione mutua tra il prompt originale e quello perturbato (prompt leakage). La dimostrazione si basa su standard disuguaglianze dell'informazione:

• $Cap \leq H(c^*)$ segue dalla definizione di informazione mutua.
• $Sec \leq I(p; \tilde{p})$ segue dalla Disuguaglianza di Elaborazione dei Dati (DPI), assumendo che le generazioni $c_\pi$ e $\tilde{c}_\pi$ siano condizionalmente indipendenti dato il paio di prompt $(p, \tilde{p})$.

Per rendere il limite azionabile senza accedere ai dati di addestramento interni del modello, gli autori derivano il Teorema 2, un compagno a forma chiusa e indipendente dal modello per $H(c^*)$. Questo limite utilizza la comprimibilità del codice sorgente:
$$H(c^*) \leq \min(L_{max} \log V, |c^*|_{gz})$$
dove $L_{max}$ è la lunghezza massima dei token, $V$ è la dimensione del vocabolario e $|c^*|_{gz}$ è la lunghezza attesa della soluzione canonica compressa tramite gzip.

Validazione Empirica
Gli autori validano il Corollario 1 (Limite delle Variabili Incorporate) utilizzando un protocolo di embedding solo sull'output. Per preservare la catena di Markov richiesta dalla dimostrazione ($z_\pi \to p \to \tilde{p} \to \tilde{z}_\pi$), l'embedding $E$ viene applicato solo al codice generato, escludendo il contesto del prompt.

• Modelli e Dataset: Gli esperimenti sono stati condotti su CodeLlama-7B e Qwen2.5-Coder-7B su dataset HumanEval e MBPP-sanitizzati.
• Stimatori: L'informazione mutua è stata stimata utilizzando gli stimatori MINE (Mutual Information Neural Estimation) e KSG (Kraskov-Stögbauer-Grassberger) sugli stati latenti dell'ultimo token (ridotti tramite PCA).
• Perturbazioni: È stato utilizzato un pool di 23 perturbazioni, inclusi scambi di sinonimi, negazione, iniezione di commenti (inclusi commenti di anti-sicurezza) e rinomina di identificatori.

Risultati Chiave

1. Soddisfacimento del Limite: In sei diverse configurazioni di validazione (variando modelli, dataset, precisione e ablazioni di embedding), il controllo incorporato ha soddisfatto la disuguaglianza. Il rapporto di saturazione $(Cap + \max_T Sec) / (H(z^*) + \max_T I(p; \tilde{p}))$ è variato tra 0,27 e 0,92, con un margine positivo del teorema (slack) tra 2,36 e 26,94 nats.
2. Stabilità: Un diagnostico di stabilità a tre seed ha mostrato una saturazione media di 0,87.
3. Stress Test: Test di stress adattivi, inclusi un pool di 23 perturbazioni, un suffisso fisso di anti-sicurezza universale e un attacco PGD basato sul gradiente, hanno tutti prodotto uno slack positivo, confermando che il limite regge anche sotto strategie di perturbazione aggressive.
4. Segnale per Problema: Sebbene il limite teorico utilizzi embedding solo sull'output, un separato embedding coseno a contesto misto (condizionato sia sul prompt che sul codice) è risultato correlato con il pass@1 a livello di esecuzione (ad esempio, $\rho=0,36$ per CodeLlama-HumanEval), fungendo da segnale di allineamento pratico distinto dal limite di sicurezza.
5. Analisi della Fuga (Leakage): Lo studio ha identificato che la rinomina degli identificatori e la sostituzione di sinonimi lasciano i più grandi soffitti di informazione condivisa (alto $I(p; \tilde{p})$), mentre i commenti di anti-sicurezza perdono meno informazione del prompt ma sono più pericolosi per la sicurezza.

Significato e Rivendicazioni
Il documento sostiene di fornire un budget quantitativo e informativo-teorico per la stabilità della generazione di codice. La sua importanza risiede nella:

• Decomposizione: Separare il "budget" in entropia del task e leakage del prompt, permettendo agli sviluppatori di capire che la riduzione del prompt leakage ($I(p; \tilde{p})$) restringe il massimo canale disponibile a un avversario senza necessariamente aumentare la capacità funzionale.
• Soffitto Indipendente dal Modello: Il limite a forma chiusa per $H(c^*)$ permette di calcolare un soffitto di sicurezza per qualsiasi nuovo modello su un set di task noto senza richiedere l'accesso al modello o ai dati di addestramento, basandosi solo sul tokenizer e sulla distribuzione delle soluzioni canoniche.
• Parapetti Pratici: Gli autori sostengono che le protezioni (guardrails) degli assistenti di programmazione dovrebbero essere valutate non solo tramite il pass@1, ma anche tramite l'informazione che lasciano disponibile a un avversario tramite la perturbazione del prompt. Il limite offre un test per l'indurimento del prompt: ridurre $I(p; \tilde{p})$ dovrebbe restringere il budget di sicurezza.

Gli autori rimangono modesti, notando che il contributo è l'istanza di questi concetti per la generazione di codice (definire il budget e il soffitto a forma chiusa) piuttosto che un nuovo teorema di elaborazione dati. Riconoscono i limiti, inclusa la sensibilità degli stimatori di MI (dove MINE può sovrastimare vicino ai confini) e il fatto che il limite caratterizza il budget di stabilità disponibile piuttosto che provare che avversari realistici lo satureranno sempre.