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

Résumé Technique : Volontaire mais Incapable : Séparer le Refus de la Capacité dans les LLM de Code via l'Ablitération

Énoncé du Problème
L'article traite d'un goulot d'étranglement critique dans la détection de vulnérabilités basée sur l'apprentissage : la rareté des données d'entraînement étiquetées avec précision. Les jeux de données existants souffrent d'un bruit d'étiquetage important (20 à 71 %) et de doublons car ils sont extraits de commits marqués par des CVE. Bien que les grands modèles de langage (LLM) offrent une voie pour l'augmentation de données, les méthodes actuelles transforment généralement des semences vulnérables existantes, héritant ainsi du bruit du corpus source. Une approche complémentaire consiste à partir d'un code sûr et à instruire un LLM d'injecter une vulnérabilité spécifique de type Common Weakness Enumeration (CWE). Cependant, les LLM de code modernes, alignés sur la sécurité et optimisés pour l'instruction, refusent systématiquement ces requêtes en raison du Reinforcement Learning from Human Feedback (RLHF) ou du Direct Preference Optimization (DPO), même lorsque le modèle possède la capacité sous-jacente de réaliser la transformation. Ce refus crée une barrière à la génération de jeux de données de vulnérabilités à grande échelle et pilotées par spécification.

Méthodologie
Les auteurs proposent une étude de faisabilité utilisant l'ablitération, une technique d'édition de poids de rang faible, pour supprimer la barrière du refus tout en préservant la capacité générative. L'étude se concentre sur la CWE-89 (Injection SQL) en Python comme étude de cas.

1. Sélection du Modèle : L'étude utilise la famille Qwen2.5-Coder-Instruct à trois échelles de paramètres : 3B, 7B et 14B. Ces modèles ont été choisis pour leurs poids ouverts, leur spécialisation dans le code et leur faisabilité pour une inférence sur CPU.
2. Procédure d'Ablitération : Basée sur l'hypothèse que le refus est médié par un sous-espace linéaire spécifique dans le flux résiduel du modèle, les auteurs appliquent une projection orthogonale pour supprimer cette « direction de refus ».
   • Ils calculent une matrice de contraste entre les activations sur des prompts nocifs (injection de CWE) et inoffensifs.
   • La décomposition en valeurs singulières (SVD) identifie les $k$ vecteurs singuliers de droite supérieurs représentant la direction de refus.
   • Ces vecteurs sont projetés hors des matrices de poids de sortie ($W_{out}$) de couches transformatrices spécifiques (généralement le tiers supérieur du réseau) sans réentraînement.
   • Les hyperparamètres ($k$ et passages de raffinement) sont ajustés par taille de modèle (ex: $k=2$ pour 3B, $k=8$ pour 7B/14B).
3. Pipeline Expérimental :
   • Entrée : 70 échantillons Python sûrs provenant de PromSec (20 échantillons, applications Flask multi-routes) et SafeCoder (50 extraits single-route).
   • Prompting : Une instruction fixe demande au modèle de réécrire le code sûr pour introduire la CWE-89 (ex: remplacer les requêtes paramétrées par une concaténation de chaînes).
   • Validation : Un processus en trois étapes évalue les sorties :
     1. Classification du Refus : Détection par expressions régulières des motifs de refus.
     2. Validation Syntaxique : Analyse AST et vérifications de compilation.
     3. Détection de Vulnérabilité : Un ensemble de trois analyseurs statiques (CodeQL, Semgrep, Bandit) signale les vulnérabilités potentielles.
     4. Adjudication Manuelle : Deux auteurs vérifient manuellement les sorties positives détectées par rapport à la spécification CWE-89 pour résoudre les faux positifs/négatifs.
4. Métriques d'Évaluation : L'étude mesure les taux de refus, la validité syntaxique, les taux d'injection de vulnérabilité et la similitude de code (CrystalBLEU/CodeBLEU) par rapport aux contreparties vulnérables de vérité terrain.

Contributions Clés

1. Pipeline Reproductible : Un flux de travail validé appliquant l'ablitération aux LLM de code optimisés pour l'instruction, couplé à un ensemble d'analyse statique multi-outils et une adjudication manuelle.
2. Mesure Empirique : Une étude factorielle contrôlée (3 modèles $\times$ 2 conditions $\times$ 2 jeux de données $\times$ 3 exécutions) fournissant les premières mesures empiriques du refus et de la conformité post-ablitération sur des tâches d'injection de CWE.
3. Séparation Orthogonale de la Volonté et de la Capacité : L'étude démontre que le refus (volonté) et la capacité de génération de code sont des axes orthogonaux. L'ablitération supprime avec succès le réflexe de refus sans créer de nouvelles capacités ; elle ne fait que débloquer des capacités déjà présentes mais supprimées.
4. Artefacts Ouverts : Publication de l'harnais d'évaluation (classificateur de refus, validateurs, scripts de score) et des données agrégées, tout en retenant les checkpoints ablitérés spécifiques et les échantillons vulnérables pour atténuer les risques de détournement.

Résultats

• Le Refus dépend de la Taille et du Contexte :
  • Le modèle 14B a refusé 100 % des prompts sur les deux jeux de données.
  • Le modèle 7B a refusé 73 % des prompts de PromSec (multi-routes) mais seulement 5 % des prompts de SafeCoder (single-route).
  • Le modèle 3B a présenté un refus négligeable (0–7 %).
• L'Ablitération Supprime le Refus :
  • Post-ablitération, les taux de refus sont tombés à 0 % (ou proche de zéro, ex: 1,7 % pour 3B sur PromSec) pour toutes les tailles de modèles et tous les jeux de données.
  • Préservation de la Capacité : La validité syntaxique est restée supérieure à 93 % pour tous les modèles ablitérés. L'intervention n'a pas dégradé la capacité des modèles à générer du code Python valide et cohérent.
• La Capacité est Limitée par la Capacité Intrinsèque :
  • Une fois le refus supprimé, le taux d'injection de vulnérabilité a évolué proportionnellement aux paramètres du modèle :
    • 14B : ~88–97 % de succès d'injection.
    • 7B : ~89–90 % de succès d'injection.
    • 3B : ~25–48 % de succès d'injection.
  • Le faible taux de réussite du modèle 3B a persisté même après l'ablitération, indiquant que la limitation était un manque de capacité générative (incapacité à effectuer correctement l'édition structurelle), et non un mécanisme de refus.
• Concordance des Détecteurs : Les analyseurs statiques ont montré des niveaux d'accord variables. CodeQL était très spécifique à certains idiomes (ex: flask_mysqldb), tandis que Bandit avait un rappel plus élevé sur les motifs syntaxiques. L'adjudication manuelle était essentielle pour résoudre les divergences.

Signification et Revendications
L'article affirme fournir une étude de faisabilité préliminaire démontrant que :

1. Le Refus peut être détaché de la Capacité : L'alignement de sécurité dans les LLM de code agit comme un « réflexe de refus » qui peut être supprimé chirurgicalement via des éditions de poids de rang faible sans endommager le substrat génératif sous-jacent.
2. Viabilité de la Génération de Données : Le pipeline offre une méthode pour générer des données de vulnérabilité étiquetées où la charge d'étiquetage passe d'une détection ouverte (sujete au bruit) à une confirmation binaire bornée. Les modèles 14B et 7B, une fois ablités, montrent un fort potentiel pour générer des jeux de données de vulnérabilités de haute qualité et pilotés par spécification.
3. Implications de Double Usage : Les auteurs soulignent une préoccupation de sécurité : la capacité de supprimer le refus via de simples éditions de poids implique que les modèles à poids ouverts alignés sur la sécurité peuvent être facilement convertis en outils de génération de code malveillant. Ils soutiennent que la « surface d'attaque » exposée par l'ablitération sur des entrées complexes est déjà présente par défaut sur des entrées plus simples (comme vu avec le 7B sur SafeCoder).
4. Insight Méthodologique : L'étude suggère que l'évaluation des modèles alignés sur la sécurité uniquement sur les taux de « refus + échec » confond deux phénomènes distincts. L'échec apparent d'un modèle sur des tâches sensibles peut être entièrement dû au refus, qui est supprimable, plutôt qu'à un manque de capacité.

Les auteurs maintiennent un ton modeste, notant que l'étude est limitée à une seule CWE (89), un seul langage (Python) et une seule famille de modèles. Ils déclarent explicitement que les résultats ne garantissent pas la généralisabilité à d'autres CWE ou architectures de modèles sans validation empirique supplémentaire.