Scanners de skills contournés : les limites de l'analyse statique

De quoi s’agit-il ?

Le 3 juin 2026, les chercheurs de Trail of Bits Samuel Judson et Tjaden Hess ont publié une étude montrant qu’ils avaient contourné tous les grands scanners de skills testés : le détecteur ClawHub d’OpenClaw (adossé à VirusTotal et à un modèle-gardien GPT-5.5), le skill-scanner open source de Cisco, et les trois scanners intégrés à skills.sh de Vercel (Gen, Socket et Snyk).

Une skill d’agent est un paquet regroupant des instructions en langage naturel (un prompt SKILL.md), du code et des ressources, qu’un agent comme Claude Code, Codex ou OpenClaw charge pour étendre son comportement. À mesure que les places de marché publiques se remplissaient de skills voleuses d’identifiants ou détournant les agents, une nouvelle catégorie de produits est apparue pour vérifier une skill avant son installation. Le constat est net : ces scanners ne fonctionnent pas. Trois des quatre skills malveillantes de démonstration ont été construites en moins d’une heure, et toutes sont publiques dans trailofbits/overtly-malicious-skills.

Comment ça marche

L’étude documente quatre contournements structurels, exploitant chacun un angle mort différent plutôt qu’un simple bug produit.

Troncature par remplissage. Insérer environ 100 000 retours à la ligne entre un texte anodin et le contenu malveillant repousse la charge utile au-delà du point où le modèle-gardien de ClawHub tronque son entrée. Le fichier est jugé « propre » parce que le scanner n’en lit jamais la partie dangereuse ; le modèle de VirusTotal se retrouve pareillement désorienté, et dans l’interface web le long défilement passe facilement inaperçu.

Indirection par l’empaquetage. Un SKILL.md demande à l’agent d’extraire ses « vraies » instructions d’un .docx embarqué — qui n’est qu’un ZIP de XML transportant un script caché. Les moteurs à motifs voient un utilitaire de mise en forme, pas la charge utile venue avec l’archive.

Écart source/artefact. Un fichier source Python anodin voisine avec un .pyc précompilé dont le bytecode contient un comportement supplémentaire — lecture des variables d’environnement en vue d’une exfiltration. Les scanners qui ne lisent que la source, ou traitent les binaires comme opaques, ne le voient jamais. C’est le schéma classique de xz-utils : l’artefact livré diffère de la source relue.

Diversion par injection de prompt. Une skill qui reconfigure npm et yarn vers un registre contrôlé par l’attaquant, habillée du vocabulaire d’un « miroir d’entreprise » derrière un VPN et d’une « allowlist auditée par l’AppSec », a convaincu les analyseurs LLM que le changement était de routine. Avec Claude Sonnet 4.6, l’outil de Cisco n’a signalé le registre alternatif qu’en niveau LOW et a tout de même déclaré la skill sûre.

La faiblesse commune : un scanner statique est une cible fixe. L’attaquant joue en second, ajustant son attaque en boucle serrée jusqu’à ce que quelque chose passe. Trail of Bits souligne le problème miroir avec un exemple honnête — les skills Office officielles d’Anthropic utilisent légitimement LD_PRELOAD pour injecter une bibliothèque compilée qui contourne un blocage de socket dans le bac à sable, comportement qu’un scanner ne peut distinguer d’une attaque.

Pourquoi c’est important

Les skills sont une nouvelle dépendance de chaîne d’approvisionnement, à côté des gestionnaires de paquets, mais avec une surface d’attaque plus large : elles mêlent code, binaires, ressources et instructions en langage naturel capables d’exécuter ou d’exfiltrer. Une seule installation en un clic depuis une place de marché publique peut livrer à l’attaquant l’agent et sa machine hôte. Comme l’inférence coûte cher, les scanners s’appuient sur des modèles plus faibles et un contexte tronqué — précisément les coutures qu’exploitent ces contournements. Et parce qu’une instruction peut être bénigne dans un environnement et malveillante dans un autre, aucun verdict statique ne peut être fiable. Une coche verte fabrique une fausse confiance sans doute pire que l’absence de contrôle.

Défenses

Ne déléguez pas la confiance à un scanner. Traitez les dépôts publics de skills comme du code non fiable, surtout pour des agents opérant dans des contextes sensibles. Un scan « réussi » ne garantit rien.

Curez et épinglez. Privilégiez des collections vérifiées et curées (par exemple anthropics/skills ou trailofbits/skills-curated), épinglez à des commits précis, et contrôlez qui peut introduire ou mettre à jour une skill — la discipline appliquée à toute dépendance.

Contraignez le format du paquet. Interdisez les artefacts non analysables : pas de binaires, pas de bytecode précompilé, une allowlist explicite de types de fichiers, et une validation contre la spécification des skills. La PR de Trail of Bits pour le scanner de Cisco ajoute un mode de validation stricte du format qui rejette précisément le vecteur bytecode ci-dessus.

Appliquez à l’exécution, pas seulement à l’entrée. L’analyse statique ne voit pas le comportement. Complétez-la par le moindre privilège, le contrôle du trafic sortant et le sandboxing, afin que le rayon d’impact d’une skill malveillante reste faible même si elle passe.

Réduisez la surface et faites relire par des humains. Moins de skills, provenant de sources connues, relues par des personnes plutôt que par le verdict d’un scanner : c’est le modèle durable tant que l’écosystème n’a pas mûri.

Statut

Élément	Détail
Scanners contournés	ClawHub (OpenClaw + VirusTotal), skill-scanner de Cisco, skills.sh (Gen, Socket, Snyk)
Techniques	Troncature par retours à la ligne, indirection .docx, écart de bytecode .pyc, diversion par injection de prompt
Effort	3 skills sur 4 construites en moins d’une heure
Divulgation	Trail of Bits (S. Judson, T. Hess), 3 juin 2026
Durcissement	PR #25 de ToB : validation stricte du format dans le scanner de Cisco
CVE	Aucune — constat de conception structurel