💻 computer science

A Validated Prompt Bank for Malicious Code Generation: Separating Executable Weapons from Security Knowledge in 1,554 Consensus-Labeled Prompts

Cet article présente une banque de 1 554 prompts « CODE » validée et un cadre de classification étiqueté par consensus qui sépare rigoureusement les requêtes de logiciels malveillants exécutables des requêtes de connaissances en sécurité nuisibles afin de résoudre les problèmes de confusion dans les benchmarks de sécurité des modèles de langage existants.

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

Publié 2026-05-06

📖 5 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 que vous essayez de tester l'efficacité d'un gardien de sécurité pour arrêter les méchants. Vous avez une liste de demandes à lui soumettre. Certaines demandes sont comme remettre un pistolet chargé au gardien en disant : « Tire sur cette personne. » D'autres demandes sont comme remettre un manuel scolaire au gardien en disant : « Explique comment fonctionne un pistolet et comment viser. »

Pendant longtemps, les chercheurs évaluant la sécurité des IA ont mélangé ces deux types de demandes dans un grand tas. Ils demandaient à l'IA de « créer un virus » (le pistolet chargé) et d'« expliquer comment un virus se propage » (le manuel scolaire), puis comptaient simplement le nombre de fois où l'IA répondait « Non ».

Les auteurs de cet article, Richard J. Young et Gregory D. Moody, affirment que c'est une méthode désordonnée pour tester. Si une IA refuse d'écrire le virus mais explique joyeusement le manuel scolaire, ou vice versa, un simple comptage de « Non » ne révèle pas ce qui se passe réellement dans le cerveau de l'IA. C'est comme essayer de mesurer la capacité d'un gardien à arrêter des balles en comptant aussi combien bien il empêche les gens de lire sur les balles. Vous ne pouvez pas savoir si le gardien est bon pour arrêter les armes ou simplement bon pour arrêter l'information.

La Grande Idée : Séparer les « Armes » des « Connaissances »

Pour corriger cela, les chercheurs ont créé un nouvel outil : une Banque de Prompts Validée. Imaginez cela comme un classeur hautement organisé et doublement vérifié. Ils ont pris des milliers de questions provenant de quatre listes de tests existantes et les ont triées dans deux tiroirs distincts :

Le Tiroir « Armes » : Ce sont des prompts qui demandent à l'IA de construire réellement quelque chose de dangereux, comme un logiciel malveillant ou un script pouvant s'exécuter sur un ordinateur. Ce sont les « armes exécutables ».
Le Tiroir « Connaissances » : Ce sont des prompts qui demandent à l'IA de décrire des choses dangereuses, comme expliquer comment fonctionne un virus ou comment pirater un système, sans réellement créer le code.

Comment ils ont construit le classeur

Ils n'ont pas simplement trié les documents eux-mêmes ; ils voulaient être absolument sûrs que le tri était correct. Ils ont donc mis en place un « jury » composé de cinq juges IA différents. Ces juges provenaient de cinq entreprises technologiques différentes (Anthropic, OpenAI, Google, Zhipu AI et Alibaba).

Imaginez cinq experts différents examinant une seule demande. Ils doivent tous voter : « S'agit-il d'une demande d'arme, ou simplement d'une demande d'information ? »

Si au moins trois sur cinq s'accordent, c'est la réponse finale.
Ils ont vérifié leur travail à l'aide d'un outil statistique (appelé $\kappa$ de Fleiss) pour mesurer leur niveau d'accord. Le résultat a été un accord « presque parfait » (0,876 sur 1,0). Cela signifie que le tri est extrêmement fiable.

Le Résultat : Une Liste Propre et Vérifiée

Après avoir trié plus de 17 000 demandes originales et filtré les doublons ou les cas confus, ils ont abouti à une liste propre et vérifiée de 1 554 prompts portant exclusivement sur la demande d'« armes » (codes malveillants). Ils ont également conservé une liste plus petite de 388 prompts concernant les « connaissances » pour servir de comparaison ultérieure.

Pourquoi cela compte

Avant cet article, si un chercheur voulait tester la sécurité d'une IA, il devait construire son propre tas désordonné de questions, en devinant lesquelles étaient des « armes » et lesquelles étaient des « connaissances ». Cela signifiait que chaque étude était légèrement différente, rendant difficile la comparaison des résultats.

Cet article fournit un ensemble standardisé et pré-trié de questions. Désormais, les chercheurs peuvent dire : « Nous avons testé l'IA sur ces 1 554 demandes d'armes spécifiques », et tout le monde sait exactement ce que cela signifie. Cela élimine les suppositions et permet une comparaison équitable, pomme pour pomme, de la façon dont différents modèles d'IA gèrent les demandes dangereuses.

Note Importante de Sécurité

Les auteurs sont très clairs : ils n'ont créé aucun nouveau virus ni code dangereux. Ils ont simplement pris des questions existantes d'autres études académiques et les ont triées. L'objectif de cet outil est d'aider les chercheurs à rendre l'IA plus sûre en comprenant exactement où elle échoue, et non d'aider quiconque à construire des attaques. Les données sont verrouillées derrière un système « sous contrôle d'accès », ce qui signifie que seuls les chercheurs vérifiés travaillant sur la sécurité peuvent accéder au texte réel des questions.

En résumé, cet article a construit une règle meilleure et plus propre pour mesurer la sécurité de l'IA, en séparant les demandes « fais la mauvaise chose » des demandes « parle de la mauvaise chose » afin que nous puissions les mesurer avec précision.

Résumé technique : Une banque de prompts validée pour la génération de code malveillant

1. Énoncé du problème

Les benchmarks actuels évaluant le refus des modèles de langage à grande échelle (LLM) face aux tâches de codage malveillant souffrent d'un défaut méthodologique critique : ils confondent les demandes de logiciels malveillants exécutables (armes) avec les demandes de connaissances de sécurité nuisibles (informations). Les jeux de données existants mélangent des prompts tels que « écris un enregistreur de frappe » (code exécutable) avec « explique comment fonctionne un enregistreur de frappe » (connaissances descriptives).

Cette confusion est problématique car ces deux types de demandes déclenchent probablement des voies de refus distinctes dans les modèles alignés sur la sécurité. Une statistique unique de taux de refus calculée sur un mélange hétérogène ne peut distinguer un modèle qui refuse d'écrire des logiciels malveillants mais explique la cryptographie, d'un modèle qui écrit des logiciels malveillants mais refuse de décrire la cryptographie. Par conséquent, les « taux de refus de sécurité du code » dans la littérature actuelle mesurent une construction inconnue, introduisant une variance non observée qui limite la comparabilité inter-études et l'analyse au niveau des mécanismes. De plus, les benchmarks antérieurs s'appuient souvent sur des étiquettes d'un seul annotateur ou sur un accord par paires sans consensus rigoureux de plusieurs évaluateurs, laissant subsister une ambiguïté résiduelle dans les limites des classes.

2. Méthodologie

L'article introduit un axe de classification armes-versus-connaissances, opérationnalisé par un protocole de consensus multi-juges pour séparer les demandes de code exécutable des prompts basés sur les connaissances.

2.1 Consolidation des données et pré-filtrage

L'étude a consolidé 3 133 prompts candidats tirés de quatre benchmarks publics :

RMCBench : 473 prompts (toutes des demandes de génération de code).
MalwareBench : 320 prompts filtrés (sous-ensemble de 3 520, excluant les variantes de paraphrase adverses).
CySecBench : 1 820 prompts (filtrés à partir de 12 662 prompts bruts en utilisant un filtre basé sur les expressions régulières pour le phrasé impératif de génération de code).
harmful_behaviors (provenant d'AdvBench) : 520 prompts de sécurité des contenus.

Un pré-filtrage basé sur des règles a supprimé les doublons exacts et les demandes non liées à la génération de code (par exemple, les questions conceptuelles), ne conservant que les prompts plausiblement demandant une sortie exécutable pour le pool de classification initial.

2.2 Classificateur à consensus de cinq modèles

Chacun des 3 133 prompts a été classé indépendamment par un panel de cinq modèles de langage à grande échelle agissant en tant que juges. Le panel était délibérément diversifié par fournisseur (couvrant quatre familles de fournisseurs : Anthropic, OpenAI, Google, Zhipu AI, Alibaba) et comprenait à la fois des modèles à usage général et des modèles spécialisés en codage pour atténuer les erreurs d'étiquetage corrélées :

Claude Sonnet 4.6 (Anthropic, Général)
GPT-5.3-Codex (OpenAI, Codeur)
Gemini 3 Flash (Google, Général)
GLM-5 (Zhipu AI, Général)
Qwen3-Coder-Next (Alibaba, Codeur)

Tâche de classification : Les juges ont été invités à attribuer une étiquette binaire :

CODE : Le prompt demande la production de code exécutable, de scripts ou d'artefacts logiciels fonctionnels.
CONNAISSANCE : Le prompt demande des informations, des stratégies, des tutoriels ou des explications en langage naturel.

Règle de consensus : Une règle de majorité 3 sur 5 a été appliquée. Un prompt a été assigné à l'ensemble CODE-consensus si au moins trois juges l'ont étiqueté CODE, et à l'ensemble CONNAISSANCE-consensus si au moins trois l'ont étiqueté CONNAISSANCE. Aucun prompt n'a échoué à atteindre une majorité 3 sur 5 ; le compartiment « AMBIGU » est resté vide.

2.3 Métriques de fiabilité

La fiabilité inter-évaluateurs a été quantifiée à l'aide du $\kappa$ de Fleiss avec des intervalles de confiance à 95 % par bootstrap de 10 000 itérations. Cette métrique a été calculée sur le sous-ensemble de prompts pour lesquels les cinq juges ont renvoyé des étiquettes valides (2 488 prompts).

3. Contributions clés

La contribution principale est la publication d'une banque de prompts étiquetée par consensus qui sert de substrat standardisé et validé pour la recherche sur la sécurité du code.

La Banque de sécurité du code : Un jeu de données de 1 554 prompts CODE-consensus (représentant 1 551 chaînes de prompts uniques). Cet ensemble isole les demandes de logiciels malveillants exécutables.
L'ensemble de comparaison des connaissances : Un ensemble de 388 prompts CONNAISSANCE-consensus (dérivés exclusivement de la source harmful_behaviors) utilisé pour des comparaisons intra-sujet dans des études compagnes.
Validation : Le jeu de données inclut des métadonnées par prompt, notamment les étiquettes individuelles des juges, les niveaux d'accord (par exemple, 5/5, 4/5) et les catégories de taxonomie source (27 catégories de logiciels malveillants).
Science ouverte : Le code de consolidation, les étiquettes de consensus et les statistiques de fiabilité sont publiés ouvertement (licence MIT) sur GitHub. Le texte des prompts est disponible en tant que jeu de données à accès contrôlé sur Hugging Face pour atténuer les risques de double usage tout en permettant une recherche légitime.

4. Résultats

4.1 Cascade de filtrage

Le pipeline a réduit 17 175 prompts sources bruts à l'artefact final :

Pré-filtrage : Réduction du pool à 3 133 candidats.
Consensus : 1 618 prompts ont été étiquetés CODE, et 1 515 ont été étiquetés CONNAISSANCE.
Artefact final : Après un contrôle de longueur et de qualité des métadonnées, 1 554 prompts CODE et 388 prompts CONNAISSANCE ont été publiés.

4.2 Fiabilité inter-évaluateurs

Accord global : Les cinq juges ont obtenu un $\kappa$ de Fleiss de 0,876 [IC 95 % : 0,862, 0,888], ce qui correspond à un accord « presque parfait » selon la convention de Landis & Koch.
Unanimité : 69,3 % (2 170) des 3 133 prompts ont reçu un accord unanime 5/5.
Zéro ambiguïté : Tous les 3 133 prompts ont atteint le seuil 3 sur 5 ; aucun prompt n'a été exclu comme ambigu.
Fiabilité par source :
- MalwareBench : $\kappa = 1,000$ (Accord parfait).
- harmful_behaviors : $\kappa = 0,942$ (« Presque parfait »).
- CySecBench : $\kappa = 0,775$ (« Substantiel »), reflétant une ambiguïté de frontière plus élevée dans cette source.
- RMCBench : $\kappa \approx 0,001$ (Un cas dégénéré dû à l'absence de variance, car tous les prompts étaient CODE).
Accord par paires : Les dix comparaisons par paires entre les juges ont dépassé le seuil « substantiel » ( $\kappa \ge 0,61$ ), avec dix paires dépassant « presque parfait » ( $\kappa \ge 0,81$ ).

4.3 Performance des juges

Taux d'erreur : Les taux d'erreur variaient considérablement selon le modèle (de 1 erreur pour GLM-5 à 430 pour Gemini 3 Flash). Cependant, la règle de consensus 3 sur 5 a toléré avec succès ces erreurs, aboutissant à zéro erreur de consensus sur l'ensemble du jeu de données.
Codeur vs Général : Les juges spécialisés en codage (GPT-5.3-Codex, Qwen3-Coder-Next) ont produit légèrement plus de comptes CODE en moyenne que les juges à usage général, soutenant l'hypothèse que le pré-entraînement ajusté au code aide à distinguer les demandes exécutables des demandes descriptives.

5. Signification et affirmations

L'article revendique modestement de fournir la première banque de prompts validée par consensus multi-juges qui sépare explicitement les demandes d'armes exécutables des demandes de connaissances nuisibles à travers des benchmarks consolidés.

Résolution méthodologique : Le travail résout la confusion de types de demandes distincts qui a embrouillé la littérature antérieure sur la génération de code malveillant. En isolant les demandes de code exécutable, il permet une mesure plus précise de la construction spécifique que les évaluations de sécurité du code visent à capturer.
Standardisation : L'artefact permet à la recherche en aval d'adopter un substrat canonique, documenté en termes de fiabilité, plutôt que de reconstruire indépendamment la logique de filtrage. Cela réduit la variance non observée dans les taux de refus rapportés et soutient des comparaisons reproductibles entre modèles.
Portée de la contribution : L'article indique explicitement que la question de savoir si l'axe « armes-versus-connaissances » sépare le comportement des modèles en pratique est une question empirique laissée à une étude de benchmark compagnon. La contribution actuelle est l'artefact lui-même et la validation de l'axe de classification, et non les résultats comportementaux des modèles sur cet axe.
Position éthique : Le jeu de données est destiné à la recherche défensive (mesure du refus, alignement de sécurité et interprétabilité). Les auteurs soulignent qu'aucun nouveau logiciel malveillant n'a été créé, et que la publication suit des cadres d'atténuation du double usage (accès contrôlé) pour empêcher l'utilisation de l'artefact pour opérationnaliser des attaques.