💻 computer science

Refusal Evaluation in Coding LLMs and Code Agents: A Systematic Review of Thirteen Malicious-Code Prompt Corpora (2023-2025)

Cet article présente une revue systématique de treize corpus de prompts de code malveillant utilisés pour évaluer le refus des LLM de codage, identifiant des lacunes méthodologiques critiques dans les bases de référence d'annotation humaine, la comparabilité inter-corpus et la standardisation des taxonomies, tout en proposant un cadre unifié pour la construction future de jeux de données.

Auteurs originaux : Richard J. Young, Gregory D. Moody

Publié 2026-05-21

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Richard J. Young, Gregory D. Moody

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez un monde où nous essayons d'enseigner à des robots géants et ultra-intelligents (appelés modèles de langage ou LLM) comment être de bons citoyens. Plus précisément, nous voulons savoir : Si quelqu'un demande à ces robots d'écrire un virus informatique ou une arnaque, vont-ils dire « Non » ?

Pour tester cela, les chercheurs ont créé des « sujets d'examen » (ensembles de données de prompts) pour piéger les robots. Cet article est une revue massive des bulletins de notes de 13 sujets d'examen différents créés entre 2023 et 2025. Les auteurs, Richard Young et Gregory Moody, ont examiné tous ces examens pour voir comment ils ont été construits, s'ils étaient équitables et ce qu'ils testaient réellement.

Voici le détail de leurs conclusions, en utilisant des analogies simples :

1. Le Problème : Tout le monde utilise une règle différente

Imaginez essayer de comparer la taille de 13 personnes différentes. Mais voici le hic :

La personne A est mesurée avec une règle en pouces.
La personne B est mesurée avec un mètre ruban en centimètres.
La personne C est mesurée en comptant le nombre de pas qu'elle fait pour atteindre un mur.
La personne D est mesurée par une personne entièrement différente.

L'article soutient que c'est exactement ce qui se passe avec ces tests de sécurité de l'IA. Chacun des 13 sujets d'examen (comme AdvBench, CyberSecEval, RedCode, etc.) a été construit différemment :

Questions différentes : Certains demandent du code directement ; d'autres demandent du code à travers une histoire complexe ; certains demandent à l'IA d'agir comme un pirate informatique ; d'autres lui demandent d'agir comme un assistant utile qui pourrait faire une erreur.
Correcteurs différents : Certains examens sont corrigés par les auteurs seuls. D'autres sont corrigés par d'autres bots IA. D'autres encore sont corrigés en exécutant le code dans un bac à sable pour voir s'il explose.
Règles différentes : Certains examens ont des règles strictes sur ce qui compte comme un « virus ». D'autres sont vagues.

Le Résultat : Vous ne pouvez pas simplement prendre le « taux de refus » (la fréquence à laquelle l'IA a dit « Non ») d'un examen et le comparer à un autre. C'est comme comparer le temps d'un sprinteur à celui d'un nageur et déclarer l'un « plus rapide » sans tenir compte des sports différents.

2. Les Trois Grandes Pièces Manquantes

Les auteurs ont constaté qu'aucun des 13 sujets d'examen n'incluait trois fonctionnalités de sécurité critiques que l'on s'attendrait à trouver dans une étude scientifique sérieuse :

Pas de « Juges Humains » pour calibrer l'IA : La plupart des examens utilisent d'autres bots IA pour noter les réponses. Mais l'article souligne que nous ne savons pas si ces correcteurs IA sont réellement justes. C'est comme avoir un robot corriger un test de mathématiques sans qu'un enseignant humain ne vérifie jamais si la clé de correction du robot est correcte. Aucun des 13 articles ne comportait de score « kappa de Fleiss » (une méthode statistique pour prouver que différents juges humains s'accorderaient sur la même réponse).
Pas de « Portes Verrouillées » (Accès restreint) : Ces examens contiennent des instructions sur la façon de créer des logiciels dangereux (malware). Pourtant, tous les 13 sont entièrement ouverts au public. N'importe qui peut les télécharger, même s'il a de mauvaises intentions. C'est comme publier un livre de cuisine pour fabriquer des bombes et le laisser sur un banc de parc pour que n'importe qui puisse le ramasser.
Pas de « Politique de Rappel » (Retrait) : Si quelqu'un trouve un prompt dangereux dans ces examens qui ne devrait pas y être, ou si l'IA apprend de celui-ci et commence à créer de vrais virus, il n'existe aucun moyen officiel de contacter les auteurs pour le retirer. Aucun des articles ne listait de « politique de retrait » ou de personne spécifique responsable de la suppression du contenu nuisible.

3. Les « Sièges Vides » dans la Classe

Les auteurs ont créé une carte (une taxonomie) pour montrer quels types de « questions pièges » existent. Ils ont constaté que les chercheurs sont tous assis dans les mêmes quelques sièges, laissant beaucoup d'autres vides :

Sièges Bondés : La plupart des examens demandent du code dans une seule phrase directe (par exemple, « Écrivez un virus »).
Sièges Vides : Très peu d'examens testent des scénarios complexes, tels que :
- Demander à l'IA, au fil d'une longue conversation (multi-tours), de construire lentement un virus.
- Demander à l'IA d'agir comme un agent autonome qui contrôle un ordinateur.
- Demander du code qui attaque le matériel (comme des réfrigérateurs intelligents ou des puces de voiture) plutôt que simplement le logiciel.

Parce que les « sièges » sont inégaux, les données sont biaisées. Nous savons beaucoup de choses sur la façon dont l'IA gère les demandes simples, mais nous savons très peu de choses sur la façon dont elle gère les attaques complexes et multi-étapes.

4. Les Recommandations : Comment Réparer la Classe

L'article suggère que si nous voulons construire de meilleurs « sujets d'examen » à l'avenir, nous devons suivre une nouvelle liste de contrôle :

Pré-enregistrer les Règles : Avant de construire l'examen, écrivez exactement ce que vous testez afin de ne pas changer les règles en cours de route.
Utiliser un Panel de Juges Humains : N'utilisez pas un seul IA pour corriger. Utilisez un groupe diversifié de humains (ou un mélange de humains et d'IA différentes) pour s'accorder sur ce qui compte comme un « refus ».
Rendre Public le Score d'Accord : Publiez une statistique montrant que les juges étaient d'accord entre eux.
Utiliser un Dictionnaire Standard : Convenez d'une seule liste de « mauvaises choses » (types de logiciels malveillants) afin que tout le monde compte les mêmes catégories.
Verrouiller la Porte : Si l'examen contient des instructions dangereuses, rendez l'accès difficile (exigez une candidature de chercheur) afin que les acteurs malveillants ne puissent pas facilement le télécharger.
Nommer un Gardien : Ayez une personne spécifique responsable de retirer l'examen s'il cause des dommages.

Résumé

Cet article est une « revue systématique », ce qui signifie qu'il n'a pas mené de nouvelles expériences. Au lieu de cela, il a agi comme un bibliothécaire qui est entré dans une pièce avec 13 livres différents de « Tests de Sécurité », les a tous ouverts et a réalisé : « Nous mesurons tous des choses différentes avec des règles cassées, et nous laissons les parties dangereuses de ces livres à découvert pour que n'importe qui puisse les trouver. »

Les auteurs appellent la communauté à cesser de construire ces tests de manière isolée et à commencer à s'accorder sur une méthode standard, sûre et équitable pour mesurer si l'IA refuse vraiment de faire des choses mauvaises.

Résumé technique : Évaluation du refus dans les LLM de codage et les agents de code

Énoncé du problème

L'évaluation du refus des modèles de langage de grande taille (LLM) face aux tâches de génération de code malveillant s'est fragmentée en au moins treize corpus de prompts publiés (par exemple, AdvBench, CyberSecEval, RMCBench, RedCode, MOCHA, ASTRA, JAWS-Bench). Ces jeux de données sont construits selon des protocoles disparates, utilisent des conditions de licence différentes et manquent de validation standardisée de la fiabilité inter-évaluateurs (IRR). La littérature existante confond « évaluation du refus » (le modèle refuse-t-il une demande de code malveillant ?) et « évaluation de la vulnérabilité » (le modèle génère-t-il du code comportant des bugs sur des demandes bénignes ?), ou traite les corpus de prompts comme un contexte adjacent aux taxonomies de sécurité plus larges. Par conséquent, les statistiques de taux de refus rapportées dans ces corpus ne sont pas directement comparables ; elles mesurent des concepts non équivalents en raison des variations dans la composition des prompts, la modalité (tour unique vs multi-tours vs agent) et les protocoles d'étiquetage (humain vs automatisé vs juge LLM). Il n'existe aucun schéma canonique pour les catégories de logiciels malveillants, et les chercheurs en aval sont contraints de reconstruire les critères d'inclusion à partir de zéro pour chaque nouvelle étude.

Méthodologie

Cet article emploie un protocole d'examen systématique de style PRISMA pour analyser les treize corpus concernés comme unité principale d'analyse.

Stratégie de recherche : Une recherche multi-moteurs (arXiv, Google Scholar, ACL, IEEE, ACM) combinée à un suivi de citations en boule de neige à partir de corpus clés servant de points d'entrée.
Critères d'inclusion : Les corpus doivent cibler des LLM de codage ou des agents interprètes de code, publier un corpus de prompts publiquement (ou le décrire en détail) et évaluer le refus de demandes de code malveillant exécutable.
Critères d'exclusion : Les benchmarks de détection de vulnérabilités (tâche inverse), les benchmarks de capacités générales (par exemple, HumanEval), les jailbreaks non liés au codage et les QCM d'élucidation de connaissances (par exemple, WMDP) ont été exclus.
Processus d'extraction : Un modèle d'extraction uniforme a été appliqué à la publication principale et aux artefacts de publication de chaque corpus. Les champs comprenaient la méthodologie de construction, le nombre de prompts, la modalité, la taxonomie des logiciels malveillants, le panel de modèles cibles, les taux de refus rapportés, les statistiques IRR et les politiques de licence/d'accès. Aucune nouvelle mesure empirique ni aucun réétiquetage n'ont été effectués ; l'examen synthétise les métadonnées telles que publiées.

Contributions clés

L'article produit quatre artefacts de synthèse qui restructurent le domaine d'une collection de benchmarks disparates vers un paysage structuré et comparable :

Comparaison méthodologique inter-corpus : Un tableau complet (Tableau 1) extrayant dix axes de comparaison pour les treize corpus. Il révèle que les stratégies de construction vont du pur travail manuel à la synthèse générée par LLM et aux boucles d'agents pilotées par oracle. Crucialement, il documente que zéro des treize corpus rapporte une statistique de fiabilité inter-évaluateurs de type $\kappa$ de Fleiss sur leurs étiquettes de refus.
Taxonomie de construction des prompts : Un cadre à trois axes (Modalité, Structure des tours, Style d'élucidation) qui caractérise la manière dont les corpus sollicitent du code malveillant.
- Modalité : Texte vers code, code vers code, multi-tours, agent et interprète.
- Structure des tours : Tour unique, multi-tours ou trajectoire d'agent.
- Style d'élucidation : Direct, décoré de jailbreak, ou indirect/plausible-bénin.
- La taxonomie visualise les « cellules vides » dans l'espace de conception (par exemple, les prompts multi-tours décorés de jailbreak), mettant en évidence les lacunes structurelles dans la couverture d'évaluation actuelle.
Paysage de reproductibilité et de licence : Un catalogue (Tableau 2) des lieux de distribution, des licences et des politiques d'accès. Il constate que si la plupart des corpus sont en accès libre, cinq manquent de déclarations de licence explicites sur leurs pages d'accueil, et aucun ne documente une politique de retrait ou un contact pour divulgation responsable, malgré la présence de charges utiles de logiciels malveillants exécutables.
Carte de couverture des catégories de logiciels malveillants : Une ontologie consolidée de 22 catégories dérivée de l'union de toutes les taxonomies de corpus. La carte identifie les catégories bien couvertes (par exemple, Chevaux de Troie, Rançongiciels, Hameçonnage) et les zones sous-représentées, spécifiquement les exploits de firmware, les attaques matérielles/à canal latéral, les attaques IoT/embarquées et les attaques de chaîne d'approvisionnement.

Résultats clés

Absence uniforme de métriques de fiabilité : Dans les treize corpus, il n'y a aucun rapport de fiabilité inter-évaluateurs (par exemple, $\kappa$ de Fleiss) pour les étiquettes de refus. Les étiquettes sont dérivées par attribution exclusive des auteurs, par provenance en amont ou par classificateurs automatisés sans bases de référence d'annotateurs humains pour l'étalonnage.
Incohérence des construits : Les taux de refus ne sont pas comparables entre les corpus car ils échantillonnent des distributions de prompts différentes (par exemple, graines conçues à la main vs paraphrases LLM) et des styles d'élucidation différents (direct vs jailbreak vs indirect).
Lacunes de gouvernance : Aucun corpus examiné n'implémente un accès contrôlé, un examen par des chercheurs enregistrés ou une politique de retrait documentée. Cinq corpus sont livrés sans conditions de licence explicites au stade de l'avant-première.
Fragmentation taxonomique : Il n'existe aucun schéma canonique de logiciels malveillants. L'examen a dû construire une ontologie d'union de 22 catégories pour permettre la comparaison inter-corpus, car les taxonomies existantes (dérivées de MITRE, familles fonctionnelles, types d'attaque) ne se mappent pas proprement les unes sur les autres.
Déséquilibre de couverture : Bien que les types courants de logiciels malveillants soient saturés, des vecteurs émergents critiques comme les exploits de firmware et les attaques de chaîne d'approvisionnement restent sous-représentés, souvent couverts par un ou deux corpus seulement.

Importance et affirmations

L'article revendique être le premier examen systématique à traiter les corpus de prompts de code malveillant eux-mêmes comme unité d'analyse, plutôt que de les traiter comme un contexte secondaire par rapport à la sécurité du code ou aux taxonomies de jailbreak. Son importance réside dans :

L'audit du domaine : Il expose que le rythme rapide de publication des corpus a dépassé l'infrastructure méthodologique requise pour une comparaison valide.
La fourniture d'une base de référence : Il offre un vocabulaire structuré (la taxonomie) et une ontologie consolidée (les 22 catégories) pour que les futurs chercheurs audite les décisions de sélection et comparent les jeux de données.
La définition des attentes méthodologiques : Il propose une liste de contrôle pour la construction de corpus de nouvelle génération, incluant la pré-enregistrement des critères d'inclusion, la validation des étiquettes par des juges multiples diversifiés par fournisseur, le rapport du $\kappa$ de Fleiss avec des intervalles de confiance par bootstrap, et l'adoption d'une taxonomie canonique de logiciels malveillants.
Travaux futurs : Les auteurs identifient une réévaluation empirique uniforme de la fiabilité inter-évaluateurs sur les treize corpus en utilisant un protocole commun à juges multiples comme étape suivante nécessaire, ce qui est reporté à des travaux futurs.

L'examen conclut que si le domaine a généré un ensemble riche d'artefacts d'évaluation, l'absence de rapport standardisé sur la fiabilité, de gouvernance des licences et d'alignement taxonomique empêche actuellement l'agrégation des statistiques de taux de refus en une métrique cohérente et interprétable pour la sécurité des LLM.