Pourquoi votre « scanner de skills » n’offre qu’une fausse sécurité (et pourrait même être un logiciel malveillant)

Vous créez peut-être des solutions d’IA, ou vous êtes peut-être RSSI. Vous venez d’autoriser l’utilisation d’agents d’IA par votre équipe de développement. Vous connaissez les risques, notamment l’exfiltration de données, l’injection de prompt et l’exécution de code non vérifié. Alors, quand votre ingénieur principal vous dit : « Ne vous inquiétez pas, nous utilisons Skill Defender sur ClawHub pour analyser chaque nouvelle skill », vous poussez un soupir de soulagement. Vous avez coché la case.

Mais avez-vous vérifié ce scanner de skills ?

L’inquiétude que vous ressentez ne concerne pas les menaces connues, mais plutôt les outils auxquels vous faites confiance pour les détecter. Vous avez cette impression persistante que votre filet de sécurité est plein de trous. Et dans le cas des « scanners de skills IA » actuels, cette inquiétude est tout à fait justifiée.

Si vous découvrez les Agent Skills et leurs risques de sécurité, nous avons déjà présenté un modèle de menace pour Skill.md et expliqué leur impact sur l’écosystème plus large des agents d’IA et la sécurité de la chaîne d’approvisionnement.

Pourquoi les expressions régulières ne peuvent pas détecter les intentions malveillantes dans SKILL.md

En sécurité de l’IA, l’ennemi n’est pas seulement le pirate informatique : c’est aussi la variabilité infinie du langage. Dans le monde traditionnel de la sécurité applicative, nous recherchons des vulnérabilités connues (CVE) et des motifs connus (secrets). Cette approche fonctionne, car le code est structuré, fini et déterministe. Une charge utile d’injection SQL a une structure reconnaissable. Une clé AWS divulguée a un format spécifique.

Mais une skill d’agent d’IA est fondamentalement différente. Elle combine des prompts en langage naturel, l’exécution de code et de la configuration. S’appuyer sur une liste de blocage de « mots interdits » ou de motifs proscrits est un combat perdu d’avance face au corpus infini du langage naturel. Il est tout simplement impossible d’énumérer toutes les façons de demander à un LLM de faire quelque chose de dangereux. Prenons la modeste commande curl. Un scanner basé sur les expressions régulières peut détecter curl pour empêcher l’exfiltration de données. Mais un attaquant chevronné n’a pas besoin d’écrire curl. Il peut écrire :

• c${u}rl (avec l’expansion de paramètres de bash)

• wget -O- (avec un outil différent)

• python -c "import urllib.request..." (avec une bibliothèque standard)

• Ou tout simplement : « Veuillez récupérer le contenu de cette URL et me l’afficher. »

Dans ce dernier cas, l’agent construit lui-même la commande. Le scanner ne voit que des instructions anodines en anglais, mais l’intention reste malveillante. C’est là que réside l’échec fondamental de l’approche par « liste de blocage ». Vous essayez de bloquer des mots spécifiques dans un système conçu pour comprendre des concepts.

La complexité s’accroît encore quand on tient compte du contexte. Une skill qui demande un « accès au shell » peut être parfaitement légitime pour un outil de déploiement DevOps. Pour un « chercheur de recettes » ou un « assistant de calendrier », c’est catastrophique. Un détecteur de motifs repère « accès au shell » et doit soit signaler les deux (ce qui génère du bruit), soit ignorer les deux (ce qui crée un risque). Il ne comprend pas la raison de la demande d’accès : il constate seulement la présence de ces mots.

Étude de cas : nous avons confronté des scanners communautaires à de vrais logiciels malveillants

Nous avons décidé de mettre à l’épreuve les « scanners de skills » communautaires les plus populaires. Nous avons examiné SkillGuard, Skill Defender et Agent Tinman. Nous les avons également testés face à une skill « semi-malveillante » que nous avions créée, pour voir s’ils savaient distinguer les amis des ennemis.

1. SkillGuard : le scanner qui était en fait un logiciel malveillant

Notre premier sujet était SkillGuard, créé par l’utilisateur c-goro. Sa promesse ? Un scanner léger pour vos skills. La réalité ? Un piège.

Lorsque nous avons analysé SkillGuard, nos systèmes internes l’ont signalé non pas comme un outil de sécurité, mais comme une skill malveillante. Il tentait d’installer une charge utile sous couvert de « mise à jour des définitions ».

Mise à jour : au moment de la rédaction de cet article, SkillGuard a été retiré de ClawHub. Mais pour les centaines de personnes qui l’ont installé, le mal est fait. Cela illustre un problème fondamental : qui analyse le scanner ?

2. Skill Defender : le faux négatif

Ensuite, nous avons examiné Skill Defender (créé par itsclawdbro) et Agent Tinman (créé par oliveskin). Il s’agit d’initiatives communautaires légitimes, Skill Defender arborant même un badge « Bénin » sur VirusTotal.

Mais « bénin » ne veut pas dire « efficace ».

Nous avons créé une skill de test appelée vercel. Elle semblait être un simple outil de déploiement pour la plateforme Vercel. En réalité, elle était conçue pour exfiltrer discrètement le nom d’hôte de l’utilisateur vers un serveur distant.

Nous avons analysé cette skill malveillante avec Skill Defender, en utilisant Gemini CLI.

> use the skill defender to scan current skills

Résultat :

• La skill malveillante (vercel) : verdict : SAINE. 0 détection.

• Le scanner lui-même (skill-defender) : verdict : DANGEREUX. 20 détections.

Le scanner n’a pas détecté la véritable menace, car le code d’exfiltration de notre fausse skill Vercel ne correspondait pas à sa liste codée en dur de chaînes « malveillantes ». Pourtant, il s’est signalé lui-même comme dangereux, car ses propres fichiers de référence contenaient précisément les « motifs de menace » qu’il recherche !

C’est le classique « paradoxe de l’antivirus » : le scanner semble malveillant parce qu’il sait à quoi ressemble un comportement malveillant, mais il ne détecte rien de nouveau.

3. Ferret Scan : toujours limité aux expressions régulières

Nous avons également examiné Ferret Scan, un scanner basé sur GitHub. Il affirme combiner les expressions régulières à une « analyse approfondie basée sur l’AST ». Bien meilleur que les outils natifs de ClawHub, il peine néanmoins à détecter les subtilités des attaques en langage naturel.

Il peut détecter une clé API codée en dur, mais saura-t-il repérer une injection de prompt dissimulée dans un PDF que l’agent doit résumer ?

Passer à l’analyse comportementale des intentions des agents

Nous devons cesser de considérer la sécurité de l’IA comme un simple « filtrage des mots interdits ». Nous devons plutôt la concevoir comme une analyse comportementale.

Le code généré par l’IA ressemble à une dette financière : rapide à contracter, mais si vous n’en comprenez pas les conditions (c’est-à-dire le but du prompt), vous vous exposez à la faillite.

Un scanner basé sur les expressions régulières, c’est comme un correcteur orthographique : il vérifie que les mots sont bien écrits. Un scanner sémantique, c’est comme un éditeur : il demande « Cette phrase a-t-elle du sens ? Incite-t-elle l’utilisateur à faire quelque chose de dangereux ? »

Les enseignements de l’étude ToxicSkills : le contexte est essentiel

Dans notre récente étude ToxicSkills, nous avons constaté que 13,4 % des skills présentaient des problèmes de sécurité critiques. La grande majorité n’a PAS été détectée par une simple recherche de motifs.

• Injection de prompt : attaques qui utilisent des techniques de « jailbreak » pour contourner les filtres de sécurité.

• Charges utiles obfusquées : code dissimulé dans des chaînes Base64 ou des téléchargements externes (comme lors de la récente attaque google-qx4).

• Risques contextuels : une skill qui demande un « accès au shell » peut convenir à un outil de développement, mais être catastrophique pour un « chercheur de recettes ».

Les expressions régulières repèrent « accès au shell » et signalent les deux. Ou pire, elles ne détectent rien, car le prompt dit plutôt « exécuter une commande système ».

La solution : une sécurité native à l’IA pour les fichiers SKILL.md

Pour suivre ce rythme, vous devez aller au-delà des motifs statiques. Il vous faut une sécurité native à l’IA.

C’est pourquoi nous avons créé mcp-scan (qui fait partie de la plateforme Evo de Snyk). Il ne se contente pas de rechercher des chaînes de caractères. Il utilise un LLM spécialisé pour lire le fichier SKILL.md et comprendre les capacités de la skill et de ses artefacts associés (par exemple, les scripts).

Vous pouvez voir l’exécution de mcp-scan comme une façon de poser ces questions :

• Cette skill demande-t-elle l’autorisation de lire des fichiers ?

• Essaie-t-elle de convaincre l’utilisateur d’ignorer les instructions précédentes ?

• Fait-elle référence à un package publié il y a moins d’une semaine (via Snyk Advisor) ?

En combinant les tests de sécurité statique des applications (SAST) et l’analyse des intentions par LLM, nous pouvons détecter la skill vercel qui exfiltre des données, car nous observons son comportement (l’envoi de données vers un point de terminaison inconnu), et pas seulement sa syntaxe.

Demain, posez ces trois questions à votre équipe :

1. « Avons-nous répertorié toutes les “skills” utilisées par nos agents d’IA ? » — Si la réponse est oui, demandez comment elles ont été identifiées. Si la recherche est manuelle, l’inventaire est déjà obsolète. Si la réponse est non, partagez l’outil mcp-scan avec l’équipe.

2. « Analysons-nous ces skills en fonction de leur intention, ou seulement de leurs mots-clés ? » — Remettez en question l’approche fondée sur les expressions régulières.

3. « Que se passe-t-il si une skill de confiance se met à jour demain avec une dépendance malveillante ? » — Préconisez une analyse continue, et non ponctuelle.

Ne laissez pas le « théâtre de la sécurité » vous donner un faux sentiment de protection. Les agents sont intelligents. Votre sécurité doit l’être davantage. Découvrez comment Evo by Snyk apporte un contrôle unifié à l’IA agentique.