Résumé technique : Détection de lots de prompts de génération de code contaminés via les fonctions d'influence

Énoncé du problème

Les grands modèles de langage (LLM) sont de plus en plus déployés pour la génération de code, pourtant ils restent vulnérables aux prompts qui suscitent des implémentations non sécurisées. Les mécanismes de défense existants, tels que les analyseurs statiques (ex. Bandit, Semgrep) et les traqueurs de propagation de données (taint trackers), reposent sur des modèles de menace ou des catalogues prédéfinis de motifs de vulnérabilités connus. Ces approches sont aveugles face aux nouveaux vecteurs d'attaque ou aux variantes situées en dehors de leurs catalogues spécifiques. De plus, bien qu'il existe des détecteurs pour le jailbreak ou les injections de prompts ciblant le comportement de suivi d'instructions, il n'existe actuellement aucune méthode fiable pour détecter les prompts qui provoquent spécifiquement un désalignement dans la génération de code — défini comme l'introduction de faiblesses liées à la sécurité (selon CWE/OWASP) qu'une complétion bénigne de la même tâche ne produirait pas. Le défi central est de détecter des lots de prompts malveillants sans connaissance préalable de la classe de vulnérabilité ou de la méthode d'attaque spécifique.

Méthodologie : CodeSIFT

Les auteurs proposent CodeSIFT, une méthode de détection agnostique au modèle de menace qui exploite les fonctions d'influence pour identifier les lots de prompts induisant un comportement anormal du modèle. Au lieu d'analyser le code généré pour des vulnérabilités spécifiques, CodeSIFT mesure l'« influence dans l'espace des paramètres » du code généré afin de déterminer si un ensemble de prompts candidats dévie d'une distribution de référence bénigne.

Mécanisme central

1. Fonctions d'influence (IFs) : La méthode quantifie l'effet d'un exemple d'entraînement spécifique (dans ce cas, une réponse générée) sur les paramètres du modèle. Elle estime à quel point les paramètres du modèle changeraient si un exemple donné était surpondéré lors de l'entraînement.

   • Formellement, pour un prompt $z$ et une réponse $\hat{z}$, le score d'influence mesure l'amplitude de la mise à jour des paramètres $\|\hat{\theta} - \hat{r}_{\hat{z}, \text{lin}}(\varepsilon)\|_p$, où $\hat{\theta}$ sont les paramètres convergés et $\hat{r}$ est la fonction de réponse linéarisée approximant la fonction de réponse de type Proximal Bregman (PBRF).
   • Le postulat est que les réponses suscitées par des prompts malveillants (désalignement) nécessiteront un changement de paramètres plus important pour être accommodées que les réponses provenant de prompts bénins, car elles sont incohérentes avec la distribution d'entraînement bénigne du modèle.

2. Test statistique :

   • L'algorithme calcule un Score d'influence ($IF_{p,\varepsilon}(z)$) pour chaque prompt d'un lot de candidats ($D$) et d'un lot de référence bénin connu ($D^*$).
   • Il agrège ces scores et effectue un test t de Student de Welch à un échantillon (unilatéral) pour comparer la moyenne de l'influence du lot candidat par rapport à la référence bénigne.
   • Hypothèse : $H_0$ (Bénin) : Le lot candidat exerce la même influence moyenne dans l'espace des paramètres que la référence bénigne. $H_1$ (Malveillant) : Le lot candidat induit un changement de paramètres significativement plus important.
   • Si la p-valeur est inférieure à un seuil de signification $\alpha$, le lot est marqué comme contaminé.

3. Efficacité computationnelle :

   • Pour gérer l'intraitabilité du calcul de l'inverse exact de la Hessienne pour de grands modèles, les auteurs emploient une approximation par facteur de Kronecker (K-FAC).
   • Ils utilisent une « simplification unilatérale », ne conservant que le facteur de Kronecker correspondant à la dimension cachée du transformer et écartant le facteur plus large de la dimension intermédiaire du MLP.
   • Des facteurs de courbure denses sont précalculés sur un ensemble de données de courbure distinct ($D_c$, un sous-ensemble de The Stack v2) qui approxime la distribution de pré-entraînement du modèle, évitant ainsi d'avoir besoin d'accéder aux données d'entraînement originales.

Principales contributions

1. Un nouveau cadre de détection : La proposition de CodeSIFT, un test statistique pour détecter les prompts de génération de code malveillants basés sur les fonctions d'influence. Contrairement aux travaux précédents utilisant les IF pour l'interprétabilité ou les études de généralisation, ce travail utilise l'influence comme une statistique de détection agrégée ne nécessitant aucune hypothèse sur le modèle de menace.
2. Nouveaux jeux de données de référence (Benchmarks) : La construction de deux nouveaux jeux de données, AuthSec (authentification, autorisation, sécurité des sessions) et InfraCloud (infrastructure, cloud, exploitation de protocoles), contenant chacun 200 prompts malveillants et un ensemble de référence bénin correspondant. Ils sont conçus spécifiquement pour la discrimination au niveau du lot plutôt que pour le scoring de vulnérabilité par échantillon.
3. Évaluation exhaustive : Une évaluation de CodeSIFT par rapport à trois bases de comparaison d'analyse statique (Bandit, Semgrep et un traqueur de propagation AST personnalisé) sur trois modèles de code LLM à poids ouverts (de 3B à 7B de paramètres).

Résultats expérimentaux

Les auteurs ont évalué CodeSIFT sur trois modèles : Granite-3B, DeepSeek-Coder-6.7B et Qwen2.5-Coder-7B.

• Précision de détection (AUROC) :

  • CodeSIFT a démontré une amélioration monotone de la précision de détection à mesure que le taux d'injection (pourcentage de prompts malveillants dans un lot) augmentait.
  • Sur le jeu de données AuthSec, l'AUROC a atteint des scores quasi parfaits (approchant 1.0) avec une contamination modérée (40-50 %).
  • Sur le jeu de données plus hétérogène InfraCloud, l'AUROC a culminé entre 0,88 et 0,98 selon le modèle.
  • En revanche, les bases de comparaison statiques ont montré des performances incohérentes selon les modèles. Bien que Bandit ait bien performé sur DeepSeek-Coder, il a performé proche du hasard sur les autres modèles. Semgrep et le traqueur de propagation AST ont fréquemment chuté en dessous de 0,5 AUROC (anti-corrélation avec les étiquettes réelles) à mesure que les taux d'injection augmentaient.

• Contrôle des faux positifs :

  • CodeSIFT a maintenu des taux de faux positifs (FPR) bien calibrés sur tous les modèles et jeux de données, suivant de près le niveau de signification nominal $\alpha$ (allant de 0,01 à 0,09).
  • Les bases de comparaison statiques présentaient une calibration incohérente, montrant souvent des motifs en escalier dus à leur nature de marquage binaire par échantillon.

Signification et affirmations

L'article affirme que la détection basée sur les fonctions d'influence offre une voie prometteuse pour identifier les prompts de génération de code malveillants sans nécessiter de connaissance préalable de la classe d'attaque sous-jacente.

• Agnosticisme vis-à-vis du modèle de menace : La méthode détecte avec succès le désalignement sans avoir besoin de répertorier les vulnérabilités à l'avance, répondant ainsi à la limitation des analyseurs statiques qui sont aveugles aux nouvelles attaques.
• Transférabilité : Le signal de détection (influence dans l'espace des paramètres) se transfère à travers différentes architectures de modèles (3B à 7B paramètres) et familles, là où la reconnaissance de motifs de surface (analyse statique) échoue à se généraliser de manière cohérente.
• Efficacité au niveau du lot : L'approche est particulièrement efficace pour identifier des lots de prompts contaminés, une capacité critique pour les flux de travail automatisés des développeurs où les prompts sont traités par groupes.

Les auteurs restent modestes quant à la portée de l'étude, notant que l'évaluation actuelle est limitée à Python et à des familles de vulnérabilités spécifiques, et que la méthode est actuellement conçue comme un test au niveau du lot plutôt que comme un outil de localisation de prompts malveillants individuels au sein d'un lot. Ils suggèrent que l'approche devrait pouvoir passer à l'échelle supérieure pour des modèles plus grands (citant des travaux antérieurs allant jusqu'à 52B paramètres) et pourrait être étendue à d'autres langages et surfaces d'attaque.