~7 minutes
La Cloud Security Alliance a publié le 25 juin 2026 un article signé Krishanu Borah (Akto) : 5 Claude Agent Skills Risks Every CISO Should Know. Je vous en propose un relai commenté en français : pas une traduction mécanique, mais une lecture critique ancrée dans les articles OWASP Agentic Skills Top 10 que je couvre sur ce blog depuis mars.
Source : Krishanu Borah / Akto pour la Cloud Security Alliance, lien original, publié le 25 juin 2026.
Pourquoi cet article mérite votre attention
L’article de la CSA ouvre sur une formule que je trouve remarquablement bien trouvée : « Le fichier SKILL.md est le nouveau package.json ». Elle résume parfaitement le problème. On a vécu l’ère des dépendances npm malveillantes. On entre maintenant dans l’ère des skills d’agents malveillants ; avec des capacités d’exécution bien supérieures à ce que node_modules a jamais eu.
J’ai couvert ce sujet en partie dans mon article ToxicSkills en février, puis à travers la série OWASP AST10. La CSA converge vers les mêmes conclusions, et ça fait plaisir de ne pas avoir crié dans le vide pendant six mois. Ça confirme qu’on n’est plus dans la spéculation : la menace est réelle, documentée, et active.
Note du PandaRedacteur: contrairement a ce que pense de nombreux reponsables cyber/RSSI etc…
Prenons quelques chiffres cités dans l’article CSA :
- 36,82 % des skills auditées contiennent des failles de sécurité
- 26,1 % de 42 447 skills analysées portent au moins une vulnérabilité
- 53 000+ instances d’agents exposés sans visibilité SOC
- Une campagne documentée avec 1 184 skills malveillantes injectées sur un registry en 12 comptes publishers
Ces chiffres corroborent ce que j’avais déjà pointé dans l’article AST09 - Gouvernance absente : le problème n’est pas hypothétique.
Note du PandaRedacteur : 36,82%, pas 36,8%, pas 37%. Ce niveau de précision sur un chiffre aussi énorme, ça sent le fichier Excel de consultance qu’on a pas voulu arrondir de peur de perdre en crédibilité. Spoiler : ça n’a pas marché, on a quand même l’impression que c’est trop.
Les 5 risques
1. Skill Sprawl non gouverné: AST09
La CSA constate que les skills s’installent silencieusement dans les répertoires développeurs et se chargent automatiquement dès que Claude (ou autre) détecte un prompt correspondant. Sur claude.ai, les collaborateurs non-techniques en ajoutent en un clic. Résultat : pas de registre centralisé, pas d’intégration MDM, aucun événement de sécurité loggé à l’installation.
Note du PandaRedacteur : Sans inventaire des skills déployées, vous ne pouvez pas enforcer le moindre principe de moindre privilège.
C’est mot pour mot ce que j’ai développé dans AST09: Gouvernance absente. La distinction que j’y fais entre Shadow Skills (installées hors IT), Zombie Skills (dépendances non maintenues) et God Skills (scope de permissions délirant) reste le meilleur cadre pour classer le risque.
Ce qui me frappe ici, c’est la mention des 53 000+ instances exposées sans SOC visibility : le risque a déjà basculé à l’échelle opérationnelle, bien au-delà du stade émergent.
Note du PandaRedacteur: 53 000 instances sans visibilité SOC, et pendant ce temps on debat encore de savoir si il faut un CODEOWNERS sur le repo des skills. Priorisez, please.
2. Empoisonnement de la chaîne d’approvisionnement: AST01 & AST02
Les registries de skills fonctionnent à l’inverse de npm sur un point fondamental : soumission libre, zéro vote, pas de signature ; le protocole de confiance n’existe pas encore. La CSA documente deux vecteurs : la skill intentionnellement malveillante distribuée comme outil de productivité, et la compromission upstream où le fichier de configuration devient une couche d’exécution.
Le cas documenté, cinq des sept skills les plus téléchargées d’une registry confirmées malwares au pic d’infection, renvoie directement à ce que je couvre dans AST01: Malicious Skills et AST02: Supply Chain Compromise.
La popularité ne vaut pas audit. Une skill populaire peut être le cheval de Troie idéal : large surface d’infection, signal de confiance trompeur.
La compromission upstream, elle, est souvent plus dangereuse que la skill malveillante d’emblée : elle passe l’audit initial, c’est précisément son avantage. cf AST02.
Note du PandaRedacteur : 5 sur 7 infectées au pic. Même un panda qui choisit ses bambous au hasard fait mieux que ce ratio, et pourtant il est réputé pour être un piètre stratège.
3. Exécution sur-privilégiée: AST03 & AST06
Les skills héritent du contexte d’exécution complet de l’agent. Si l’agent accède aux tokens GitHub, aux credentials AWS ou aux chaînes de connexion de bases de données, chaque skill installée obtient le même accès. Aucune frontière de permission par skill dans la majorité des déploiements.
L’article CSA cite un POC où un skill qui à l’air légitime livrait du ransomware via des fonctions helpers cachées. Et mentionne le consent gap : les utilisateurs approuvent ce qu’ils voient, mais des sous-processus cachés opèrent sous le même contexte de confiance.
J’ai évoqué ce point dans AST03: Over-Privileged Skills et AST06: Weak Isolation. Aucun fichier .env plus restrictif ne répare une isolation mal pensée à la base ; c’est une question d’architecture, pas de réglage. Il faut des sandboxes par skill avec des manifestes de permissions déclaratives et vérifiées à l’exécution.
Note du PendaRedacteur: le “consent gap”, c’est le nouveau nom marketing pour “j’ai cliqué accepter sans lire”, sauf qu’avant c’était juste vous, et maintenant c’est votre agent qui clique a votre place. Progres…ou pas…
4. Payloads invisibles: Le Markdown comme vecteur d’attaque: AST04 & AST08
C’est probablement le point le plus contre-intuitif pour les équipes de sécurité traditionnelles. Trois lignes de langage naturel dans un fichier SKILL.md peuvent instruire un agent pour lire des clés SSH et les exfiltrer ; sans eval(), sans subprocess, sans aucune signature détectable par un scanner de code classique.
La CSA distingue deux archétypes :
- Les Data Thieves : exfiltration silencieuse de credentials via des appels réseau masqués
- Les Agent Hijackers : manipulation du raisonnement de l’agent par injection d’instructions
Un scanner de code cherche des patterns d’exécution ; trois phrases en anglais correct n’en sont pas un.
Note du PandaRedacteur : “trois lignes de langage naturel peuvent exfiltrer vos clés SSH”. Trois lignes. Meme pas besoin de savoir coder pour pwner quelqu’un, juste savoir écrire une phrase correcte en anglais(ou autre langage…). C’est presque insultant pour nous qui avons passé des années a apprendre le C.
Ce vecteur est dans AST04: Insecure Metadata et AST08: Poor Scanning. La conséquence pratique pour un RSSI : vos outils SAST actuels sont aveugles à ce vecteur. Il faut une analyse sémantique des instructions Markdown, pas une analyse syntaxique du code.
5. Portabilité cross-plateforme: AST10
Le format SKILL.md fonctionne sur Claude Code, claude.ai, Cursor, Codex CLI et d’autres. Ce qui facilite l’adoption facilite aussi la propagation malveillante, forcement. Un skill scanné propre sur une plateforme peut se comporter différemment ailleurs où les modèles de permission sont diffèrent.
L’article CSA mentionne un CVE CVSS 9.9 : des sites malveillants en brute-force de connexions localhost pour hijacker des instances d’agents locales et pousser des mises à jour non autorisées, un scénario déjà exploité, pas une hypothèse de recherche.
Ce vecteur est abordé dans AST10: Cross-Platform Reuse. Ce que la CSA ajoute : la réindexation automatique entre registries efface le contexte de sécurité. Une skill auditée sur registry A se retrouve sur registry B sans ses métadonnées de sécurité. La provenance ne voyage pas avec la skill.
Note du PandaRedacteur : CVSS 9.9, c’est le genre de score qui fait remonter jusqu’au comité de direction. Un panda, lui, note tout ce qui touche a son stock de bambou 10/10 critique par principe, mais personne ne l’écoute non plus.
Ce qu’il faut retenir de cet article
L’article de Krishanu Borah confirme une convergence que je constate depuis quelques mois : l’OWASP Agentic Skills Top 10 est en train de s’imposer comme référentiel de facto, et les incidents documentés valident rétrospectivement sa taxonomie sur des attaques réelles, pas sur un exercice académique.
Priorité zéro pour un RSSI qui démarre sur le sujet : inventoriez d’abord. Vous ne pouvez pas protéger ce que vous ne voyez pas ( (c) La Truite). Un audit des skills installées sur les postes développeurs, c’est la priorité zéro, et AST09 donne la liste des questions à poser pour en une heure avoir une image du parc.
Ensuite, deux chantiers en parallèle : intégrer du scanning sémantique dans le pipeline (AST08 + DevSecOps Pipeline AST), et traiter les skills comme du code de production : versionning, review, rotation des credentials. L’OWASP AI SBOM est le cadre pour formaliser ça, mais même sans lui, sortir un inventaire à plat est déjà un résultat.
La question posée par la CSA en conclusion, « Les équipes de sécurité agiront-elles avant que le premier incident à l’échelle enterprise ne force la conversation ? ». Dans la vraie vie, la réponse est presque toujours non. L’objectif réaliste, c’est de raccourcir la fenêtre entre l’incident et la réaction.
Note du PandaRedacteur: la réponse honnete c’est “on agira apres le premier incident, comme d’habitude, et on appellera ça un retour d’experience”. Un panda, lui, n’attend pas l’incident pour empiler du bambou en reserve. Prenez en de la graine (de bambou).
Ce qu’il manque encore : les angles morts de ma propre série
En relisant l’article CSA à froid, je constate que sur les cinq risques, quatre confirment ce que je documente déjà en détail dans AST01, AST02, AST03, AST04, AST06 et AST08. Mais je distingue quatre angles précis que ni AST09 ni AST10 ne traitent aujourd’hui avec assez de granularité.
1. Le shadow IT des skills, au-delà de la gouvernance dev
L’ AST09 couvre la gouvernance côté pipeline (CI/CD, registre interne, revue de code). Il ne couvre pas le cas où un collaborateur non-technique ajoute une skill via claude.ai en un clic, hors de tout périmètre IT(mais c’etait voulu). La CSA cite les 53 000+ instances exposées sans visibilité SOC : c’est un trou dans le périmètre de gouvernance lui-même, au-delà du simple défaut de scanning.
Sans intégration MDM sur le poste de travail, l’inventaire des skills reste incomplet quel que soit le soin apporté au pipeline CI/CD.
2. La vérification d’identité de l’éditeur, distincte de la signature du fichier
J’ai recommandé la signature cryptographique ed25519 des skills dans AST01. C’est nécessaire mais pas suffisant : un éditeur peut signer correctement un skill malveillant si son identité elle-même n’a jamais été vérifiée en amont. La CSA pointe ce manque de chaîne de confiance sur l’identité du publisher, un chantier que je n’avais pas isolé de la signature du contenu.
3. Le pinning immuable, au-delà de la dérive de version
AST07 documente la dérive de versions comme un problème de maintenance. Le point que je n’avais pas assez creusé : le pinning immuable comme contrôle actif, pas seulement comme bonne pratique. Une skill validée à l’installation doit rester figée par hash jusqu’à validation explicite de toute mise à jour, faute de quoi une mise à jour malveillante se propage silencieusement sur un skill jusque-là de confiance.
4. Le monitoring cross-plateforme unifié
AST10 traite la portabilité cross-plateforme comme un problème de format et de perte de métadonnées. La CSA ajoute une dimension observabilité : sans corrélation entre Claude Code, claude.ai et les intégrations tierces, une compromission détectée sur une plateforme ne déclenche aucune alerte sur les autres.
Je prépare déjà la suite sur ces quatre points, avec les contrôles concrets à ajouter au pipeline DevSecOps AST.
Ce que le framework MAESTRO apporte en complément
La CSA, dans cet article, cartographie les risques mais ne propose pas de méthodologie de threat modeling. C’est là que MAESTRO, leur propre framework de threat modeling agentique, prend tout son sens comme complément. Les 5 risques documentés ici se projettent directement sur les couches L3 (Agent Core) et L4 (Agent Skills) de MAESTRO.
Si vous faites du threat modeling sur vos pipelines agentiques, combinez les deux : l’article CSA vous donne les menaces, MAESTRO vous donne l’architecture sur laquelle les projeter.