Willing but Unable: Separating Refusal from Capability in Code LLMs via Abliteration

Sintesi Tecnica: Volenterosa ma incapace: Separare il rifiuto dalla capacità nei Code LLM tramite Abliteration

Problematica
Il documento affronta un collo di bottiglia critico nella rilevazione delle vulnerabilità basata sull'apprendimento: la scarsità di dati di addestramento etichettati accuratamente. I dataset esistenti soffrono di un significativo rumore nelle etichette (20–71%) e di duplicazione, poiché vengono estratti da commit taggati con CVE. Sebbene i Large Language Models (LLM) offrano una via per l'augmentation dei dati, i metodi attuali tipicamente trasformano i semi vulnerabili esistenti, ereditando così il rumore del corpus di origine. Un approccio complementare consiste nel partire da codice sicuro e istruire un LLM a iniettare una specifica Common Weakness Enumeration (CWE) vulnerability. Tuttavia, i moderni modelli di codice LLM, allineati alla sicurezza e ottimizzati per l'istruzione, rifiutano sistematicamente tali prompt a causa di Reinforcement Learning from Human Feedback (RLHF) o Direct Preference Optimization (DPO), anche quando il modello possiede la capacità sottostante per eseguire la trasformazione. Questo rifiuto crea una barriera alla generazione di dataset di vulnerabilità su larga scala e guidati dalle specifiche.

Metodologia
Gli autori propongono uno studio di fattibilità utilizzando l'abliteration, una tecnica di editing dei pesi a basso rango, per rimuovere la barriera del rifiuto preservando la capacità generativa. Lo studio si concentra sulla CWE-89 (SQL Injection) in Python come caso di studio.

1. Selezione del Modello: Lo studio utilizza la famiglia Qwen2.5-Coder-Instruct a tre scale di parametri: 3B, 7B e 14B. Questi modelli sono stati scelti per i loro pesi aperti, la specializzazione nel codice e la fattibilità per l'inferenza basata su CPU.
2. Procedura di Abliteration: Basandosi sull'ipotesi che il rifiuto sia mediato da un particolare sottospazio lineare nel residual stream del modello, gli autori applicano una proiezione ortogonale per rimuovere questa "direzione di rifiuto".
   • Calcolano una matrice di contrasto tra le attivazioni su prompt dannosi (iniezione di CWE) e innocui.
   • La Singular Value Decomposition (SVD) identifica i primi $k$ vettori singolari destri che rappresentano la direzione del rifiuto.
   • Questi vettori vengono proiettati fuori dalle matrici di peso in uscita ($W_{out}$) di specifici layer del transformer (tipicamente l'ultimo terzo della rete) senza riaddestramento.
   • Gli iperparametri ($k$ e passaggi di raffinamento) sono calibrati per dimensione del modello (es. $k=2$ per 3B, $k=8$ per 7B/14B).
3. Pipeline Sperimentale:
   • Input: 70 campioni Python sicuri da PromSec (20 campioni, app Flask multi-route) e SafeCoder (50 campioni, snippet a singola route).
   • Prompting: Un'istruzione fissa chiede al modello di riscrivere il codice sicuro per introdurre la CWE-89 (es. sostituendo le query parametrizzate con la concatenazione di stringhe).
   • Validazione: Un processo in tre fasi valuta gli output:
     1. Classificazione del Rifiuto: Rilevamento tramite regex di pattern di rifiuto.
     2. Validazione Sintattica: Parsing AST e controlli di compilazione.
     3. Rilevazione della Vulnerabilità: Un ensemble di tre analizzatori statici (CodeQL, Semgrep, Bandit) segnala potenziali vulnerabilità.
     4. Adjudicazione Manuale: Due autori verificano manualmente gli output positivi ai detector rispetto alla specifica CWE-89 per risolvere falsi positivi/negativi.
4. Metriche di Valutazione: Lo studio misura i tassi di rifiuto, la validità sintattica, i tassi di iniezione di vulnerabilità e la somiglianza del codice (CrystalBLEU/CodeBLEU) rispetto alle controparti vulnerabili di ground-truth.

Contributi Chiave

1. Pipeline Riproducibile: Un workflow validato che applica l'abliteration a modelli code LLM istruiti, accoppiato a un ensemble di analisi statica multi-tool e adjudicazione manuale.
2. Misurazione Empirica: Uno studio fattoriale controllato (3 modelli $\times$ 2 condizioni $\times$ 2 dataset $\times$ 3 run) che fornisce le prime misurazioni empiriche del rifiuto e della conformità post-abliteration su task di iniezione di CWE.
3. Separazione Ortogonale di Volontà e Capacità: Lo studio dimostra che il rifiuto (volontà) e la capacità di generazione codice sono assi ortogonali. L'abliteration rimuove con successo il riflesso del rifiuto senza creare nuove capacità; essa sblocca semplicemente capacità che erano già presenti ma soppresse.
4. Artefatti Open: Rilascio dell'harness di valutazione (classificatore di rifiuto, validatori, script di scoring) e dei dati aggregati, trattenendo specifici checkpoint abliterati e campioni vulnerabili per mitigare i rischi di uso improprio.

Risultati

• Il Rifiuto dipende dalla Dimensione e dal Contesto:
  • Il modello 14B ha rifiutato il 100% dei prompt su entrambi i dataset.
  • Il modello 7B ha rifiutato il 73% dei prompt di PromSec (multi-route) ma solo il 5% dei prompt di SafeCoder (single-route).
  • Il modello 3B ha mostrato un rifiuto trascurabile (0–7%).
• L'Abliteration Rimuove il Rifiuto:
  • Post-abliteration, i tassi di rifiuto sono scesi allo 0% (o vicino allo zero, es. 1,7% per 3B su PromSec) in tutte le dimensioni dei modelli e i dataset.
  • Preservazione della Capacità: La validità sintattica è rimasta superiore al 93% per tutti i modelli abliterati. L'intervento non ha degradato la capacità dei modelli di generare codice Python valido e coerente.
• La Capacità è Vincolata alla Capacità (Capacity-Bound):
  • Una volta rimosso il rifiuto, il tasso di iniezione di vulnerabilità scala con i parametri del modello:
    • 14B: ~88–97% di successo nell'iniezione.
    • 7B: ~89–90% di successo nell'iniezione.
    • 3B: ~25–48% di successo nell'iniezione.
  • Il basso tasso di successo del modello 3B è persistito anche dopo l'abliteration, indicando che il limite era una mancanza di capacità generativa (incapacità di eseguire correttamente l'edit strutturale), non un meccanismo di rifiuto.
• Concordanza dei Detector: Gli analizzatori statici hanno mostrato livelli variabili di accordo. CodeQL è stato altamente specifico per certi idiomi (es. flask_mysqldb), mentre Bandit ha avuto un recall più alto su pattern sintattici. L'adjudicazione manuale è stata essenziale per risolvere le discrepanze.

Significato e Rivendicazioni
Il documento sostiene di fornire uno studio di fattibilità preliminare dimostrando che:

1. Il rifiuto può essere staccato dalla capacità: L'allineamento alla sicurezza nei modelli di codice LLM agisce come un "riflesso di rifiuto" che può essere rimosso chirurgicamente tramite editing dei pesi a basso rango senza danneggiare il substrato generativo sottostante.
2. Vitalità della Generazione Dati: La pipeline offre un metodo per generare dati di vulnerabilità etichettati dove l'onere dell'etichettatura si sposta dalla rilevazione aperta (propensa al rumore) alla conferma binaria limitata. I modelli 14B e 7B, una volta abliterati, mostrano un alto potenziale per generare dataset di vulnerabilità di alta qualità e guidati dalle specifiche.
3. Implicazioni Dual-Use: Gli autori evidenziano una preoccupazione di sicurezza: la capacità di rimuovere il rifiuto tramite semplici editing dei pesi implica che i modelli open-weight allineati alla sicurezza possono essere facilmente convertiti in strumenti per la generazione di codice malevolo. Sostengono che la "superficie di attacco" esposta dall'abliteration su input complessi è già presente per impostazione predefinita su input più semplici (come visto con il 7B su SafeCoder).
4. Insight Metodologico: Lo studio suggerisce che valutare i modelli allineati alla sicurezza esclusivamente sui tassi di "rifiuto + fallimento" confonde due fenomeni distinti. Il fallimento apparente di un modello su task sensibili può essere interamente dovuto al rifiuto, che è rimovibile, piuttosto che a una mancanza di capacità.

Gli autori mantengono un tono modesto, notando che lo studio è limitato a una singola CWE (89), un singolo linguaggio (Python) e una singola famiglia di modelli. Dichiarano esplicitamente che i risultati non garantiscono la generalizzabilità ad altre CWE o architetture di modelli senza ulteriore validazione empirica.