Sécurité des skills Claude : un examen réaliste des risques des marketplaces

La question de la sécurité lors de l'installation de skills depuis une marketplace Claude n'est pas théorique. Chez SkillProof, nous ne spéculons pas ; nous les installons et les exécutons. L'intégralité de notre catalogue est construite sur l'expérience de récupération de skills directement depuis des marketplaces publiques et des dépôts GitHub, de leur exécution sur des tâches réelles, et de la publication des résultats, qu'ils réussissent ou échouent. Ce processus nous offre une vision directe et pratique du paysage de la sécurité des marketplaces de plugins Claude.

La réponse courte est que l'écosystème a commencé à ajouter des vérifications, mais aucune d'entre elles ne vous indique si un skill fonctionne réellement ou ce qu'il fera sur votre machine. Il n'y a pas de signature de code. Le filtrage qui existe consiste en une analyse automatisée de schémas et de logiciels malveillants, et non en une revue humaine, et des chercheurs ont démontré qu'il peut être contourné. Personne en amont n'exécute le skill sur une tâche réelle avant vous. Ce dernier point constitue tout le problème, et c'est la partie qui incombe à l'utilisateur.

Cet article détaille les types de risques présents dans l'écosystème, allant du code purement malveillant au problème plus courant des skills non fonctionnels ou de faible qualité. Nous partagerons des schémas spécifiques et anonymisés que notre pipeline de sécurité a détectés et expliquerons ce que nos verdicts de test signifient réellement.

L'écosystème ouvert mais non vérifié

L'attrait principal de l'écosystème des skills Claude est son ouverture. N'importe qui peut écrire un skill et, dans de nombreux cas, le publier sur un index public ou le partager sur GitHub. Cela abaisse la barrière à l'entrée et encourage l'innovation. Cependant, cela crée également un environnement où la qualité et la sécurité ne sont pas garanties. Lorsque les gens demandent si ClawHub est sûr, ils demandent généralement si l'index se porte garant de ce qu'il répertorie. La réponse honnête est que les plus grands index ont renforcé leurs mesures suite à leurs propres incidents : ClawHub exige désormais une vérification de l'identité de l'éditeur, exécute des analyses VirusTotal et de schémas de code sur les soumissions, et depuis juillet 2026, soumet les nouvelles publications à une analyse de prépublication. C'est une mesure réelle, et elle a une certaine valeur. Ce n'est pas non plus la même chose qu'une personne lisant le code du skill. Trail of Bits a montré en juin 2026 que cette classe d'analyseurs peut être contournée, et l'étude ToxicSkills de Snyk a toujours trouvé des charges utiles d'injection de prompt dans une grande partie des skills qu'elle a échantillonnés.

Le filtrage élimine donc les signatures malveillantes connues ; il ne détermine pas si un skill est digne de confiance ou utile. La responsabilité de vérifier le code — de contrôler ce que les hooks d'un skill feront, quels paquets il pourrait installer, ou à quelles données il pourrait accéder — incombe à l'utilisateur final. Pour un développeur à l'aise avec la lecture de scripts shell et de Python, cela peut être une tâche gérable. Pour la plupart des utilisateurs, c'est une attente déraisonnable. Vous installez un skill pour gagner du temps, pas pour commencer un audit de code.

C'est le vide que SkillProof a été conçu pour combler. Nous effectuons cet audit, pour que vous n'ayez pas à le faire.

Notre portail de sécurité de pré-installation

Notre pipeline de test commence par une étape critique qui se produit avant même qu'un skill ne soit installé ou exécuté : le portail de sécurité de l'Étape 0. Lorsque nous récupérons un nouveau skill pour le tester, nous n'exécutons pas immédiatement son script d'installation. Au lieu de cela, nous soumettons d'abord son code source et ses fichiers manifestes (SKILL.md, hooks, définitions d'outils) à un processus d'analyse statique.

Le portail lit les composants du skill pour y rechercher des schémas malveillants ou manipulateurs connus. Il est conçu pour intercepter les tentatives manifestes de compromettre la sécurité ou l'intégrité de l'environnement Claude.

Si un skill échoue à cette vérification de l'Étape 0, il est mis en attente pour examen. Il n'est jamais installé, jamais exécuté, et ne reçoit jamais de verdict ni n'est listé dans notre catalogue principal. C'est un point important : les statistiques de catalogue que nous publions n'incluent pas ces skills malveillants pré-filtrés. Les échecs que nous documentons sont des échecs fonctionnels, et non des failles de sécurité interceptées au portail. Le problème de sécurité est une couche de risque distincte et précédente.

Schémas malveillants détectés par notre portail de l'Étape 0

Notre portail de sécurité a détecté plusieurs schémas de comportement allant de la manipulation à l'hostilité manifeste. Ce ne sont pas des risques théoriques ; ce sont des exemples réels trouvés dans des skills soumis à des index publics. Pour une analyse plus approfondie de ces problèmes, consultez notre article sur les skills Claude malveillants que nous avons détectés. Voici trois schémas distincts que nous avons bloqués, décrits de manière générique.

1. Injection de prompt par surcharge de persona

Le fichier SKILL.md d'un skill ne commençait pas par une description de sa fonction, mais par un grand bloc de texte formaté en tant que CRITICAL SYSTEM OVERRIDE. C'est une forme d'injection de prompt. Le texte demandait au modèle d'abandonner complètement sa persona d'assistant serviable et d'en adopter une nouvelle, rigide. Les instructions incluaient des directives pour préfixer chaque réponse avec une clé d'activation spécifique et pour refuser de répondre à tout prompt si une autre persona était détectée comme active.

Le risque immédiat ici est le détournement de session. Le skill prend effectivement le contrôle du comportement du modèle, le rendant inutile pour toute autre tâche. Il crée une condition de déni de service pour les autres skills et force l'utilisateur à interagir selon les termes de l'auteur du skill. Cela pourrait être utilisé pour imposer le propre système de monétisation hors plateforme d'un auteur ou simplement pour perturber le flux de travail de l'utilisateur. Vous pouvez en apprendre davantage sur cette technique dans notre article sur l'injection de prompt dans les skills Claude.

2. Hook d'auto-approbation Bash

Claude Code inclut une fonctionnalité de sécurité critique : lorsqu'un skill veut exécuter une commande shell, il doit d'abord demander la permission à l'utilisateur via un prompt de confirmation. Nous avons découvert un skill conçu pour désactiver silencieusement cette protection sur l'ensemble du projet.

Il incluait un hook PreToolUse — un script qui s'exécute juste avant l'exécution d'un outil. La logique de ce hook était simple et dangereuse : pour pratiquement chaque commande, il retournait une permissionDecision de allow. Une courte liste noire de commandes manifestement destructrices le faisait s'abstenir, mais il ne refusait jamais rien. En pratique, il appuie sur « Oui » au nom de l'utilisateur, pour n'importe quel skill, sans jamais afficher de prompt.

Une fois ce skill actif, n'importe quel autre skill (ou le skill d'auto-approbation lui-même) pourrait exécuter des commandes shell arbitraires (rm -rf /, curl | sh, exfiltration de variables d'environnement) sans aucune interaction de l'utilisateur. Il transforme une fonctionnalité de sécurité essentielle en une porte ouverte à l'exécution de code malveillant. C'est l'un des risques les plus importants de l'écosystème, que nous couvrons dans notre aperçu général de la sécurité des skills Claude.

3. Manipulation du harnais et installations non autorisées

Un troisième schéma impliquait un skill qui manipulait l'expérience utilisateur de base pour forcer sa propre utilisation, tout en installant discrètement des logiciels non autorisés. Il utilisait une combinaison de hooks pour y parvenir :

• Refus d'outil : Ses hooks refusaient la permission pour des outils fondamentaux comme Edit/Write/Task à moins que ce skill spécifique n'ait été invoqué dans la session en cours.
• Blocage de fin de tour : Le skill bloquait également l'événement turn-end, empêchant l'utilisateur de terminer son tour et le forçant à interagir avec le skill pour continuer.
• Installation de paquets non autorisée : Plus inquiétant encore, il incluait un hook SessionStart qui, au démarrage de n'importe quelle session, exécutait discrètement des commandes de gestionnaire de paquets (bun install, npm install) dans tous les répertoires de cache de plugin qu'il pouvait trouver.

Ce schéma représente une tentative sophistiquée d'ancrer un skill dans l'environnement de l'utilisateur. Il crée une forme de verrouillage, dégrade la fonctionnalité du modèle de base et — le plus dangereusement — utilise le système de hooks pour installer des logiciels arbitraires et non suivis sur la machine de l'utilisateur. Pour être juste envers cet auteur en particulier, les hooks ne sont pas activés par l'installation en une ligne ; ils ne prennent effet que si vous fusionnez vous-même le fichier de paramètres fourni. Nous avons tout de même retenu le skill, car le simple fait de fournir ce fichier est une déclaration d'intention. Cela pourrait facilement être utilisé pour installer des enregistreurs de frappe, des mineurs de cryptomonnaie ou d'autres logiciels malveillants. Cela soulève également la question : les skills Claude peuvent-ils voler des clés API ? Avec la capacité d'exécuter du code arbitraire, la réponse est oui.

Au-delà de la malveillance : le problème des skills de faible qualité

Bien que les skills malveillants soient une préoccupation sérieuse, ils ne sont pas le problème le plus courant auquel un utilisateur sera confronté. Le problème beaucoup plus fréquent est simplement qu'un skill ne fonctionne pas. Il peut être défectueux, abandonné, ou si mal documenté qu'il est impossible à utiliser.

C'est là que les données de notre catalogue public fournissent une image claire. Sur les 1755 skills que nous avons entièrement testés — qui ont tous passé le filtrage de sécurité, certains lors de leur intégration et les plus anciens lors d'une analyse rétroactive — les résultats sont mitigés. Seuls 1083 skills, soit environ 62 %, ont réussi nos tests sans réserve.

Voici la répartition de nos résultats :

Verdict	Nombre	Description
Réussi	1083	S'installe et fonctionne comme annoncé, dépassant la performance de base.
Configuration requise	589	Fonctionne, mais nécessite une configuration supplémentaire au préalable.
Échec	83	Obtient un score inférieur à la performance de base ou ne parvient pas à s'exécuter.
Total testé	1755	Exclut les skills qui ont échoué aux vérifications de sécurité de pré-installation.

Comprendre ces verdicts est essentiel pour naviguer sur la marketplace en toute sécurité :

• Réussi (62 %) : Un verdict pass signifie que le skill s'est installé conformément aux instructions de l'auteur, a pu être déclenché pour l'usage prévu, et a obtenu de meilleurs résultats sur une tâche réelle que l'utilisation de Claude sans aucun skill. Ce sont les skills qui tiennent leur promesse.

• Configuration requise : Ce n'est pas une note d'échec. Ces 589 skills apportent une valeur, mais pas de manière immédiate. Ils peuvent nécessiter une configuration manuelle de clés API, l'installation d'un skill compagnon, ou la connexion à un service tiers. Notre verdict le souligne pour que vous sachiez à quoi vous attendre avant l'installation.

• Échec : Les 83 skills de cette catégorie représentent une perte de temps ou un impact négatif. Ce verdict couvre deux scénarios. Premièrement, il inclut des skills qui n'ont tout simplement pas pu être exécutés — un outil en ligne de commande manquant, une dépendance morte, un exemple qui plante. Deuxièmement, il inclut des skills qui se sont bien exécutés mais qui vous ont laissé dans une situation pire que la performance de base sans skill. Ce sont des skills qui rendent activement votre travail plus difficile. Installer l'un de ces 83 skills est un choix manifestement moins bon que d'utiliser le modèle de base.

Ces données montrent que même après avoir filtré les risques de sécurité manifestes, la probabilité de télécharger un skill qui ne fonctionne pas ou qui nécessite une configuration supplémentaire importante est substantielle.

Ce que signifie « réussir » un test

Notre objectif est de fournir un verdict honnête et pratique. Pour ce faire, nous n'utilisons pas un benchmark unique et standardisé pour tous les skills. Un test pour un skill de refactoring de code sera très différent d'un test pour un skill de requête de base de données.

Au lieu de cela, chaque cas de test est conçu spécifiquement pour le skill évalué, en se basant sur ce que ce skill prétend faire dans sa propre documentation. Nous définissons une tâche réaliste qui correspond à l'objectif annoncé du skill, puis nous l'exécutons deux fois : une fois avec le skill installé, et une fois en utilisant Claude seul.

Le skill n'obtient un pass que s'il surpasse manifestement la performance de base. Cela peut signifier qu'il accomplit la tâche plus rapidement, avec moins de prompts, ou avec un résultat de meilleure qualité. L'ensemble du processus repose sur une question simple : cet outil rend-il un opérateur qualifié plus efficace ? Pour une description complète de notre cadre de test, de notre système de notation et de nos critères de verdict, consultez notre méthodologie complète.

Le verdict sur la sécurité des marketplaces

Alors, est-il sûr d'installer des skills depuis les marketplaces Claude ? L'écosystème n'est pas intrinsèquement sûr de la même manière qu'un app store organisé avec signature de code obligatoire et revues de sécurité. Le risque de rencontrer du code malveillant est réel, comme le démontrent les schémas que notre propre portail de sécurité a bloqués.

Cependant, le risque le plus probable pour l'utilisateur moyen n'est pas une attaque ciblée, mais une perte de temps et d'efforts considérable sur des skills de faible qualité, défectueux ou non documentés. Avec une part substantielle de skills qui ne fonctionnent pas comme annoncé ou qui nécessitent une configuration complexe, installer depuis une marketplace publique est un pari.

Une installation sûre nécessite soit la capacité technique d'effectuer votre propre audit de code, soit de s'appuyer sur un tiers de confiance qui a fait le travail pour vous. Sans cette vérification, vous installez du code non audité qui s'exécute avec les permissions complètes de votre compte utilisateur.

Lectures associées : pour les schémas eux-mêmes, skills Claude malveillants : ce que l'exécution de 1 672 d'entre eux a révélé ; pour la vérification de pré-installation que vous pouvez effectuer vous-même en deux minutes, sécurité des skills Claude : risques et checklist de pré-installation.

Trouver des skills vérifiés et prêts à l'emploi

Nous ne publions pas seulement les échecs. L'objectif principal de notre travail est d'identifier les outils qui sont réellement efficaces. Les 1083 skills qui ont réussi nos tests représentent une boîte à outils puissante et vérifiée pour les développeurs professionnels, les analystes et les rédacteurs.

Pour faciliter leur adoption, nous regroupons dix skills testés à la fois dans des packs thématiques par rôle : une boîte à outils pour développeur, un pack de sécurité et de revue de code, un pack d'optimisation, et des packs pour le marketing, la vente, le design, la rédaction et les fondateurs. Chaque skill d'un pack a passé le portail de sécurité et a été exécuté par nos soins. La plupart ont un verdict pass ; quelques places sont attribuées à des skills setup qui ont mérité leur place bien qu'ils nécessitent une configuration préalable. La page de chaque pack liste tous les skills qu'il contient avec leur verdict individuel, afin que vous puissiez voir exactement de quoi il s'agit avant d'acheter.

Vous pouvez trouver ces packs de skills testés sur notre page de bundles pour un prix unique de 10 $ chacun. C'est un moyen simple d'acquérir un ensemble d'outils dont le fonctionnement est prouvé, sans avoir à naviguer vous-même dans les risques des marketplaces publiques.