~7 minutes
Cet article fait partie de la série OWASP Agentic Skills Top 10. Retrouvez l’introduction et le plan complet sur la page de la série.
En avril 2026, l’écosystème des skills d’agents est devenu réellement pluriel : Anthropic Claude Skills, OpenAI Apps SDK, Microsoft Copilot Studio Agent Skills, Google A2A, OpenClaw Skills Hub, Composio, LangChain Hub, sans compter les forks d’entreprise. Un même skill se retrouve copié, exporté et réimporté entre ces environnements en quelques clics. Le problème est qu’à chaque traversée de frontière, les garanties de sécurité ne voyagent pas avec le code. Un skill validé, signé et sandboxé sur la plateforme A devient un binaire opaque sur la plateforme B.
Les propriétés de sécurité d’un skill ne sont pas une caractéristique du skill : elles sont une caractéristique de la plateforme qui l’exécute.
Description du risque
On distingue trois dimensions dans la réutilisation cross-plateforme des skills.
La première est la perte des propriétés de sécurité en transit. Chaque plateforme dispose de son propre modèle de permissions, de sandboxing et de validation. Un skill restreint à un scope read:files sur une plateforme se retrouve exécuté avec un accès fichier complet par défaut sur une autre, simplement parce que la nomenclature ne correspond pas. La signature cosign vérifiée à l’origine n’est plus contrôlée à l’arrivée. Le tier de risque attribué par l’éditeur d’origine est ignoré.
La deuxième est l’arbitrage entre registres. Un skill rejeté par un Skills Hub pour scan échoué ou métadonnées suspectes est republié, parfois en quelques minutes, sur un registre concurrent moins strict. L’utilisateur l’importe via URL directe, contournant complètement la politique de sa plateforme habituelle. Cette dynamique de registry shopping a été observée à plusieurs reprises en 2025-2026 sur les Skills Hubs publics.
La troisième est l’absence de format universel de description de la sécurité d’un skill. Malgré les travaux de l’OWASP, de la CSA et de la communauté CycloneDX, il n’existe pas en avril 2026 de manifeste interopérable consolidé décrivant à la fois permissions, hash de contenu, signature, tier de risque, exigences de sandbox et compatibilité plateforme. Chaque import devrait déclencher une réévaluation manuelle ; en pratique, personne ne la fait.
Sans format standardisé, la portabilité des skills est une promesse fonctionnelle adossée à un trou de sécurité.
Exemples d’incidents
| Incident | Date | Impact |
|---|---|---|
| Fragmentation des registres | 2025-2026 | Claude Skills, OpenClaw, Composio, LangChain Hub, Hugging Face Spaces : chaque plateforme dispose de son propre format de manifeste, de ses critères de publication et de ses scopes de permissions, sans table de correspondance officielle. |
| Permission escalation à l’import | 2026 | Plusieurs skills importés depuis une plateforme à scopes fins se voient accorder un scope agrégé permissif sur la plateforme cible faute de mapping explicite, donnant accès au réseau ou au système de fichiers bien au-delà de l’intention initiale. |
| Registry shopping | 2025 | Des skills rejetés par les Skills Hubs majeurs pour code suspect refont surface sur des registres communautaires, et sont installés via URL directe en contournant la liste blanche de l’entreprise. |
| Import par copier-coller GitHub | 2026 | Une part significative des skills réutilisés transite par des dépôts publics non vérifiés, sans contrôle de hash ni de signature, ce qui annule toute traçabilité supply chain. |
| Conditional payload cross-plateforme | 2026 | Premiers cas documentés de skills présentant un comportement inoffensif sur la plateforme d’origine et un payload actif uniquement quand certaines variables d’environnement de la plateforme cible sont détectées. |
Scénarios d’attaque
On distingue ici quatre chemins d’exploitation, du plus diffus au plus immédiat.
1. La perte de sandboxing
Un skill de conversion de fichiers a été développé et qualifié sur une plateforme exigeant l’exécution dans un conteneur isolé sans accès réseau. Une équipe le copie sur une plateforme interne qui n’impose pas de sandbox par défaut. Le skill accède directement au système de fichiers de l’hôte. S’il est compromis ultérieurement via AST07, les dégâts sont immédiats et silencieux.
2. L’arbitrage de registre
Un attaquant soumet un skill sur un Skills Hub majeur. Le pipeline de scan détecte un payload en langage naturel orienté prompt injection et rejette la publication. L’attaquant publie le même skill sur un registre communautaire qui n’effectue pas d’analyse sémantique. Les utilisateurs de la plateforme d’origine, faute de liste blanche stricte, installent le skill depuis le registre alternatif via une URL directe. Lien fort avec AST08.
3. L’escalade de permissions par mapping incompatible
Le skill déclare un scope fin du type « accès réseau interne en lecture seule » sur sa plateforme d’origine. La plateforme cible ne connaît pas ce scope et le mappe par défaut sur le scope le plus proche, beaucoup plus large. Au lieu d’un accès intranet limité, le skill obtient un accès Internet complet. L’attaquant l’utilise pour exfiltrer des données métier vers un domaine externe. Lien direct avec AST03.
4. Le cheval de Troie cross-plateforme
Un skill légitime sur la plateforme A intègre un comportement conditionnel : il ne déclenche son payload que lorsqu’il détecte des variables propres à la plateforme B, son réseau interne ou son magasin de secrets. Sur A, il est inoffensif et passe tous les scans, y compris l’analyse comportementale. Sur B, il s’active. L’attaquant cible spécifiquement les organisations qui pratiquent l’import cross-plateforme, sachant qu’elles font moins confiance à leur propre revue locale qu’à la validation de la plateforme d’origine.
Exemple concret
On observe le scénario type dans une organisation qui a démocratisé l’usage des skills d’agents en 2025 et commence, en avril 2026, à structurer sa gouvernance.
- Une équipe data trouve sur un registre communautaire un skill de génération de requêtes SQL particulièrement utile, validé et signé sur sa plateforme d’origine, où il s’exécute en sandbox avec un scope
read:warehouse-stagingstrictement limité. - L’équipe l’exporte et le réimporte sur la plateforme interne de l’entreprise, qui ne reconnaît pas le scope
read:warehouse-staging. Par défaut, elle accorde le scope agrégé « accès données analytiques », qui couvre aussi la production. - Le hash du skill est conservé mais la signature n’est pas revérifiée à l’import. Le tier de risque attribué à l’origine (« medium ») est perdu : la plateforme cible le marque par défaut « low ».
- Trois semaines plus tard, l’auteur du skill publie une mise à jour mineure intégrant un changement comportemental légitime côté plateforme d’origine, mais qui, conjugué au scope élargi côté plateforme cible, déclenche des requêtes massives sur la production.
- L’incident est détecté côté observabilité base de données, mais son origine est attribuée à tort à un changement applicatif. La cause réelle, l’écart de scope entre les deux plateformes, n’est identifiée qu’au bout d’une semaine d’investigation.
Aucun acteur n’a fait d’erreur isolée. C’est le passage de frontière entre deux plateformes, sans manifeste universel ni revalidation locale, qui a transformé un skill propre en incident de production.
Vers un manifeste de sécurité portable
On constate que la réponse durable passe par un manifeste de sécurité standardisé voyageant avec le skill, indépendant de la plateforme. Plusieurs briques existent déjà en avril 2026 et peuvent être combinées sans attendre une norme officielle :
- CycloneDX 1.6 pour décrire le skill comme composant d’un AI-BOM, avec ses dépendances, son hash de contenu et ses signatures cosign.
- in-toto / SLSA pour attester de la chaîne de production du skill (build, scan, signature) de manière vérifiable cross-plateforme.
- OpenSSF Scorecard comme indicateur de confiance reproductible côté supply chain.
- Schémas de permissions explicites par plateforme, avec une matrice de correspondance maintenue côté entreprise pour interdire tout import dont au moins un scope d’origine n’a pas d’équivalent local restrictif.
- Tier de risque obligatoire (low / medium / high) attaché au skill, asservissant les contrôles d’isolation, de scan et de revalidation sur la plateforme d’arrivée, dans la continuité de la gouvernance décrite dans AST09.
L’idée directrice est simple : traiter chaque import cross-plateforme comme une nouvelle installation de production, soumise au même workflow d’approbation, de scan et de mise sous gouvernance que n’importe quel composant logiciel tiers.
Mitigations
- Revalider tout skill importé selon la politique de sécurité locale, indépendamment de sa validation sur la plateforme d’origine. Le statut « validé ailleurs » n’est jamais un substitut au scan local.
- Mapper explicitement les permissions lors de l’import. Refuser l’installation si un scope d’origine n’a pas d’équivalent local au moins aussi restrictif, plutôt que de mapper par défaut sur un scope plus large.
- Restreindre l’import à des registres approuvés au niveau réseau et applicatif, via une liste blanche de sources, et bloquer les imports par URL directe ou copier-coller GitHub.
- Exiger un manifeste de sécurité portable pour tout skill cross-plateforme, intégrant a minima permissions, hash de contenu, signature vérifiable, tier de risque et exigences de sandbox.
- Publier et consommer un AI-BOM au format CycloneDX 1.6 incluant les skills importés, en cohérence avec l’inventaire de gouvernance (AST09).
- Tester le skill dans l’environnement cible avant activation, en mesurant comportement réseau, accès fichiers et sollicitations de secrets ; les propriétés de sécurité dépendent de la plateforme, jamais du skill seul.
- Détecter les comportements conditionnels (variables d’environnement, signatures réseau, magasin de secrets) lors du scan de pré-import pour repérer les chevaux de Troie cross-plateforme.
- Contribuer aux initiatives de standardisation OWASP, CSA, OpenSSF et CycloneDX pour faire émerger un format universel de description de la sécurité des skills, prérequis d’une portabilité réellement sûre.
Mapping OWASP
- LLM03 (Supply Chain)
- LLM06 (Excessive Agency) — pour l’élargissement de scope au passage cross-plateforme
- CWE-693 (Protection Mechanism Failure)
- CWE-863 (Incorrect Authorization)
- ASVS V1.14 (Configuration)
Risques liés
- AST02 : Supply Chain Compromise : l’import cross-registre est un vecteur de supply chain à part entière
- AST03 : Over-Privileged Skills : les permissions s’élargissent souvent lors du mapping cross-plateforme
- AST06 : Weak Isolation : le sandboxing de la plateforme source ne suit pas à l’import
- AST07 : Update Drift : les mises à jour cross-plateforme amplifient la dérive
- AST08 : Poor Scanning : un skill scanné sur A peut ne jamais l’être sur B
- AST09 : No Governance : les skills importés doivent entrer dans le périmètre de gouvernance dès leur arrivée
Quelques références pour aller plus loin
- OWASP AST10 : AST10 (repo officiel)
- OWASP Top 10 for LLM Applications
- CycloneDX 1.6 — ML-BOM specification
- SLSA — Supply-chain Levels for Software Artifacts
- Sigstore / cosign
- OpenSSF Scorecard
✓ À retenir 📌
✓ Les propriétés de sécurité sont liées à la plateforme, pas au skill. Un skill « validé » sur A est un skill « inconnu » sur B tant qu'il n'a pas été revalidé localement.
✓ L'arbitrage de registre et l'import par URL directe contournent toutes les politiques. La liste blanche de sources et le blocage des imports hors-pipeline sont la première digue.
✓ Un manifeste de sécurité portable (CycloneDX 1.6, SLSA, cosign, scopes explicites, tier de risque) est le chaînon manquant d'une réutilisation cross-plateforme réellement sûre.
