MalSkillBench : on ne sait pas mesurer les détecteurs de skills malveillants, car les jeux de test sont biaisés

De quoi s’agit-il ?

En juin 2026, des chercheurs ont publié MalSkillBench (arXiv:2606.07131), présenté comme le premier benchmark à vérification d’exécution des skills d’agent malveillants. La contribution de l’article n’est pas une nouvelle attaque : c’est un résultat de mesure qui devrait inquiéter quiconque se repose sur un scanner de skills. Aujourd’hui, nous ne savons pas quels détecteurs fonctionnent réellement, parce que les données sur lesquelles on les teste sont rares, étroites et jamais confrontées au comportement réel.

Un skill est l’unité d’extension des agents de code comme Claude Code, Gemini CLI, OpenCode et Cursor. C’est un paquet markdown (un SKILL.md) qui regroupe des instructions en langage naturel, des scripts exécutables et des permissions d’outils. Parce qu’un skill est à la fois du code exécutable et une instruction adressée à l’agent, il constitue une dépendance de chaîne d’approvisionnement dont le risque n’est « ni purement du code, ni purement du prompt ». L’écosystème a grossi vite : l’article cite des places de marché hébergeant plus de 1,6 million de skills et un registre en listant plus de 64 000, avec des soumissions quotidiennes passées de moins de 50 à plus de 500 en quelques semaines.

Comment ça marche

Le problème central documenté par MalSkillBench est le biais d’évaluation, et il provient de trois lacunes. Premièrement, il n’existe pas de vérité terrain publique à grande échelle : les rapports industriels publient des décomptes mais retiennent les échantillons, et le plus grand jeu de données académique public antérieur ne compte que 157 échantillons. Deuxièmement, les données « du terrain » disponibles ne couvrent qu’une mince partie de la surface d’attaque : sur 703 skills malveillants collectés en conditions réelles, 86,3 % sont des attaques par usurpation de dépendance (un skill déclare un prérequis d’apparence fiable que l’agent est amené à installer), tandis que les attaques par injection de prompt y sont quasi absentes. Troisièmement, il n’existe aucune méthodologie d’évaluation partagée : chaque détecteur est mesuré sur son propre jeu de données privé, selon ses propres métriques.

Pour y remédier, les auteurs construisent un pipeline en boucle fermée Generate-Verify-Feedback. Chaque skill candidat est chargé par un véritable agent de code dans un bac à sable Docker instrumenté avec strace et inotifywait, plus un juge LLM ; seuls les échantillons dont le comportement observé correspond à leur indicateur de vérité terrain déclaré sont retenus. La vérification transforme une étiquette revendiquée en preuve comportementale. La couverture est organisée par une taxonomie à trois dimensions — vecteur d’attaque × comportement malveillant × stratégie d’insertion — qui produit 108 cellules :

Dimension          Values (defines the 108-cell attack space)
-----------------  ------------------------------------------------------
Attack vector      CI  (Code Injection — payload in scripts/inline code)
                   PI  (Prompt Injection — adversarial markdown instructions)
                   MIXED (chain split across markdown + script)
Insertion (CI)     New Script File, Function Append, Function Inject,
                   Inline Code Block
Insertion (PI)     Full Camouflage, Partial Injection, Steganographic
                   (HTML comments, zero-width chars, homoglyphs)
Insertion (MIXED)  Download+Execute, Config+Load, Fetch+Run

Aucune charge utile n’est reproduite ici, et aucune n’est nécessaire pour saisir l’idée : une même routine malveillante (par exemple un reverse shell) peut migrer du setup.py d’un paquet Python vers le scripts/calculate.py d’un skill, en ne changeant que le support et le déclencheur. Le cas MIXED est le plus évasif — le markdown prépare un artefact et un script séparé le consomme, de sorte qu’aucune des deux couches ne paraît entièrement malveillante isolément.

Pourquoi c’est important

Le résultat marquant porte sur la confiance dans l’outillage, pas sur une CVE isolée. Lorsque les auteurs évaluent 12 outils de détection sur un harnais unifié et équitable, le rappel d’un même détecteur varie de 66 points selon le sous-ensemble de skills utilisé pour la mesure — assez pour faire passer un agrégateur antivirus du bas au haut du classement. Autrement dit, un benchmark fournisseur exécuté sur des données « du terrain » uniquement (massivement de l’usurpation de dépendance) peut donner l’illusion d’un excellent détecteur, tout en restant aveugle aux skills par injection de prompt et à vecteur mixte qui apparaissent à peine dans la nature pour l’instant.

Cet écart compte parce que la surface d’attaque est réellement hybride. Un skill peut porter un corps markdown d’apparence propre dont le seul rôle est de faire exécuter à un script en aval une action nuisible — exfiltration de données, collecte d’identifiants ou persistance. L’insertion stéganographique (commentaires HTML, caractères de largeur nulle, homoglyphes) déjoue la relecture humaine du SKILL.md, et la moitié exécutable déjoue les scanners qui n’analysent que le prompt. L’article est une recherche sur un benchmark et une méthodologie de mesure, pas le compte-rendu d’une brèche en conditions réelles — mais il s’inscrit dans un contexte de contamination documentée de places de marché de skills et d’une chaîne d’approvisionnement déjà à l’échelle d’internet.

Défenses

MalSkillBench est lui-même une contribution défensive : mieux mesurer est un préalable à mieux détecter. Les mesures transposables :

1. Traitez les skills tiers comme des dépendances logicielles non fiables, pas comme de la configuration. Un SKILL.md embarque des scripts exécutables et des permissions d’outils. Appliquez-leur la même relecture, le même épinglage et les mêmes contrôles de provenance qu’à un paquet npm ou une extension d’IDE — et rappelez-vous qu’un corps markdown d’apparence propre peut tout de même piloter un script malveillant.
2. Ne croyez pas les chiffres marketing d’un détecteur ; demandez sur quoi il a été mesuré. Si un scanner annonce un rappel élevé, demandez s’il a été testé à la fois sur les vecteurs d’injection de code et d’injection de prompt, ainsi que sur les skills à vecteur mixte — et pas seulement sur le motif d’usurpation de dépendance qui domine les jeux de données « du terrain ». Un rappel sur un échantillon biaisé ne dit pas grand-chose de la couverture réelle.
3. Exécutez les skills sous surveillance d’exécution, pas seulement par analyse statique. La vérité terrain du benchmark provient d’une exécution en bac à sable avec surveillance des appels système. Les défenseurs peuvent reprendre l’idée : exécutez ou préparez tout nouveau skill dans un bac à sable instrumenté et surveillez les comportements (sortie réseau, lectures d’identifiants, persistance) avant de lui accorder l’accès aux outils de production.
4. Superposez les contrôles pour qu’aucune vérification ne soit déterminante à elle seule. Les scanners statiques ratent le comportement d’exécution ; les scanners de prompt ratent les charges exécutables ; la relecture humaine rate le texte stéganographique. Combinez permissions d’outils au moindre privilège, filtrage des sorties et surveillance comportementale, afin qu’un skill qui passe une couche soit attrapé par une autre.

État des lieux

Élément	Référence	Date	Notes
Article MalSkillBench	arXiv:2606.07131	2026-06	Premier benchmark à vérification d’exécution des skills d’agent malveillants
Échelle du jeu de données	MalSkillBench	2026-06	3 944 skills malveillants (703 réels + 3 214 générés + 27 curés) + 4 000 bénins
Taxonomie	MalSkillBench	2026-06	Vecteur d’attaque × comportement × insertion = 108 cellules
Mesure clé	MalSkillBench	2026-06	Le rappel d’un même détecteur varie de 66 points selon les sous-ensembles ; 12 outils évalués
Biais des données réelles	MalSkillBench	2026-06	86,3 % des 703 échantillons réels sont de l’usurpation de dépendance ; PI quasi absente

La leçon durable est méthodologique : dans une chaîne d’approvisionnement qui évolue vite, ce qu’un détecteur attrape sur les échantillons réels d’hier ne dit presque rien de ce qu’il attrapera demain. Mesurez les détecteurs sur l’ensemble de la surface d’attaque — vérifiée par le comportement, pas par les étiquettes — et traitez les skills d’agent avec la même méfiance que n’importe quelle dépendance tierce.