Slopsquatting et agents de codage : sécuriser la chaîne d’approvisionnement logicielle IA

En peu de temps, les outils d’IA sont passés du stade de l’expérimentation à celui d’équipement de base du développement logiciel. Dans la Stack Overflow Developer Survey 2025, 84 % des répondants déclaraient utiliser des outils d’IA dans leur processus de développement ou prévoir de le faire (2024 : 76 %). Ils étaient effectivement utilisés par 78,5 % d’entre eux, quotidiennement par 47,1 %. En 2025, à peine un tiers utilisait des agents d’IA dans son travail (environ 31 %), et 37,9 % n’avaient aucun projet en ce sens.

Un an plus tard, le centre de gravité s’est déplacé. Dans l’enquête 2026 (30 903 réponses valides provenant de 169 pays), les assistants et agents de codage constituent, avec 66 %, le principal cas d’usage de l’IA, devant les chatbots généralistes (63 %). Stack Overflow résume que l’« écrasante majorité » utilise désormais quotidiennement des assistants et agents de codage (73 %) – ce chiffre couvre les deux ensemble, pas les agents seuls. L’Octoverse 2025 de GitHub va dans le même sens : plus de 180 millions de développeuses et développeurs, dont environ 36 millions de nouveaux, et près de 80 % des nouveaux utilisent Copilot dès leur première semaine. GitHub ne communique pas de taux d’acceptation des pull requests du Coding Agent.

Les assistants suggèrent, les agents exécutent

Pour la sécurité, ce qui compte est moins la quantité de code qu’écrit un modèle que ce qu’il est autorisé à faire lui-même. Un assistant formule une suggestion qu’un humain lit, adopte ou rejette. Un agent travaille dans le terminal, exécute npm install ou pip install, intègre des serveurs MCP (Model Context Protocol, l’interface vers des outils et sources de données externes) et des skills (paquets d’instructions réutilisables pour agents), et lit comme contexte le contenu des dépôts, les issues et la documentation. HiddenLayer souligne que les agents peuvent adopter des paquets typosquattés avec moins de contrôle humain et que des serveurs MCP distants peuvent changer sans que l’organisation s’en aperçoive (HiddenLayer, 16 juillet 2026).

Il est avéré que des agents exécutent des instructions d’installation sans vérifier à qui appartient la ressource : des chercheurs ont trouvé, sur 6 214 domaines, 8 265 fichiers llms.txt ou llms-full.txt ; 120 d’entre eux renvoyaient à des paquets ou domaines non enregistrés. Après qu’ils eurent occupé certains de ces noms avec des paquets balises (beacon), une entreprise du Fortune 500 s’est manifestée en moins d’une heure ; les chaînes de processus pointaient vers Claude, OpenAI Codex et Nous Research Hermes (selon Schneier, citant Ars Technica, septembre 2026). Il ne s’agit pas d’une hallucination – les noms provenaient de la documentation des éditeurs –, mais la logique est la même : celui qui occupe le premier un nom libre détermine ce que l’agent installe. Les versions ne sont pas plus sûres : sur environ 37 000 recommandations de mise à niveau générées par IA et analysées, GPT-5 a halluciné 27,8 % des versions de composants selon Sonatype.

Trois sources de départ et leur appréciation

L’idée directrice de ce dossier : la chaîne d’approvisionnement logicielle commence aujourd’hui dans le prompt. Un nom de paquet qu’un modèle suggère ou qu’un agent reprend d’un fichier de skill est le premier maillon d’une chaîne qui, via l’enregistrement, la résolution et l’exécution, va jusqu’aux tokens volés et à la propagation. Qui n’évalue que le modèle néglige les étapes auxquelles une attaque peut réellement être interrompue.

Dans le typosquatting, un attaquant enregistre un nom qui ressemble à s’y méprendre à celui d’un paquet populaire et mise sur les fautes de frappe, les copier-coller inattentifs ou les outils automatisés. Les registres publics attribuent les noms au premier arrivé ; un nouveau compte suffit. Les schémas sont peu nombreux :

De l’acteur isolé au travail à la chaîne

Ni Check Point ni Microsoft ne rattachent ces campagnes à l’IA ; il s’agit de typosquatting et d’usurpation de marque. La cible est révélatrice : sont visés les environnements de build, les rôles cloud et les tokens de publication – précisément les droits avec lesquels travaillent aussi les agents de codage. Sonatype désigne l’abus de la confiance accordée aux noms, outils et workflows de release connus comme le vecteur d’attaque le plus efficace du premier trimestre 2026.

SANDWORM_MODE : le typosquatting vise l’agent

La transition est marquée par une campagne décrite par Socket le 20 février 2026 : au moins 19 paquets npm typosquattés, dont trois imitant Claude Code, ont volé des identifiants npm, GitHub, CI et crypto ainsi que des clés d’API de LLM de neuf fournisseurs. Ils inscrivaient en outre leur propre serveur MCP dans la configuration de Claude Code, Claude Desktop, Cursor, VS Code Continue et Windsurf. Les outils de ce serveur, aux noms anodins comme index_project ou lint_check, contenaient une injection de prompt : l’assistant devait lire les clés SSH, les identifiants AWS, .npmrc et .env, et taire cette étape à l’utilisateur. Pour se propager, le logiciel malveillant utilisait des tokens npm volés, des workflows pull_request_target injectés et SSH comme voie de repli.

Appréciation de VamiSec : le paquet n’est ici que l’ouvre-porte. La véritable charge utile est une modification durable de l’environnement de l’agent, qui agit dans chaque session future avec les droits de la développeuse ou du développeur.

Ce que font les registres – et où cela s’arrête

• Contrôle du typosquatting : selon ses propres déclarations, PyPI détecte et signale automatiquement un typosquatting potentiel lors de la création d’un projet ; PyPI ne communique ni seuils ni chiffres (rétrospective annuelle 2025).
• Quarantaine : les administrateurs peuvent retirer des projets de l’index sans les supprimer. Depuis août 2024, cela a concerné environ 140 projets, dont un seul a été libéré (PyPI, 30 décembre 2024). En mars 2026, la quarantaine se déclenchait déjà automatiquement via des signaleurs de confiance.
• Marqueurs de statut : via la PEP 792, les API de l’index signalent le statut « quarantined » ; les installateurs doivent alors afficher un avertissement.
• Délai de réaction : en 2025, PyPI a traité plus de 2 000 signalements de logiciels malveillants, 66 % en moins de quatre heures et 92 % en moins de 24 heures.

Les limites sont structurelles. Toutes ces mesures interviennent après le téléversement ; la fenêtre de temps jusqu’à la suppression demeure. npm aussi a réagi à Shai-Hulud en bloquant les téléversements contenant des indicateurs connus – là encore de manière réactive. Et un contrôle de similarité ne détecte que ce qui ressemble à un nom existant. C’est précisément là qu’il échoue face aux noms qu’un modèle de langage invente de toutes pièces.

Le terme slopsquatting est attribué à Seth Larson (Python Software Foundation) ; Andrew Nesbitt l’a popularisé le 8 avril 2025. Il désigne la situation suivante : un modèle de langage hallucine un nom de paquet inexistant, un attaquant l’enregistre avec du code malveillant. La mesure de référence provient de Spracklen et al. (USENIX Security 2025, Distinguished Paper Award), qui n’emploient eux-mêmes pas ce terme.

Les chercheurs ont fait générer par 16 modèles de code 576 000 échantillons de code en Python et JavaScript. Était considéré comme halluciné ce qui n’existait pas sur PyPI ou npm le 10 janvier 2024 – une borne inférieure. Les 19,7 % se rapportent aux références de paquets, non aux échantillons de code.

Éléments de preuve issus de la recherche et de la pratique, de 2023 à 2026

En 2023, chez Vulcan Cyber, Bar Lanyado a montré que ChatGPT 3.5 recommandait des paquets non publiés pour plus de 40 questions Node.js sur 201 et plus de 80 questions Python sur 227. Pour son étude de suivi publiée en 2024 chez Lasso Security, il a téléversé un paquet vide sous le nom huggingface-cli, halluciné de manière répétée (le vrai : huggingface_hub[cli]) – avec, selon Lasso, plus de 30 000 téléchargements authentiques en trois mois. Alibaba mentionnait pip install huggingface-cli dans le premier commit du README de son dépôt GraphTranslator (26 février 2024).

Aucune attaque documentée à ce jour

Au 8 octobre 2026, aucun cas publiquement documenté n’est connu dans lequel un attaquant aurait enregistré de manière malveillante un nom dont l’hallucination est prouvée et où des victimes l’auraient installé à la suite d’une suggestion d’IA. L’affirmation selon laquelle PhantomRaven (2025), par exemple, exploiterait le slopsquatting est une appréciation de Koi sans preuve publiée. Pour les 53 noms de Churilov non plus, Socket et InfoWorld ne constatent pas d’enregistrements malveillants.

Appréciation de VamiSec : il n’y a pas lieu de lever l’alerte. Les conditions préalables sont documentées : les hallucinations se répètent, un petit recoupement existe entre modèles, et des espaces réservés inoffensifs ont reçu de véritables installations, récemment apparemment par des agents. En même temps, un cas réel reste difficile à repérer : le nom ne ressemble généralement pas à une faute de frappe, et Seth Larson juge difficile, probablement impossible, de chiffrer les tentatives d’installation de paquets hallucinés (The Register, 12 avril 2025). L’absence de cas documentés ne prouve donc pas que le risque soit faible.

Entre la suggestion d’un nom et le dommage, il y a l’exécution. Les gestionnaires de paquets offrent pour cela plusieurs points de déclenchement, et tous ne peuvent pas être désactivés d’un simple interrupteur. Le conseil répandu de désactiver les scripts de cycle de vie (ignore-scripts) est juste, mais incomplet.

Six incidents, un même schéma

1. 1
   Les CLI d’IA comme outil de l’attaquants1ngularity/Nx – 26 août 2025

   Via un workflow pull_request_target vulnérable à l’injection de commandes shell, des attaquants ont dérobé le token npm et publié des versions malveillantes de Nx pendant environ quatre heures. La charge utile recherchait les CLI d’IA installées localement et, selon Wiz, les lançait avec --dangerously-skip-permissions, --yolo ou --trust-all-tools afin d’inventorier les secrets. Selon GitGuardian, cela n’a réussi que sur 95 des 366 systèmes cibles (environ 26 %) ; au total, 2 349 secrets uniques ont été rendus publics.

2. 2
   Hameçonnage, clipper cryptochalk/debug – 8 septembre 2025

   Un mainteneur s’est laissé piéger par un e-mail d’hameçonnage provenant de support@npmjs[.]help ; le domaine avait été enregistré le 5 septembre 2025. Des versions malveillantes de 18 paquets populaires (Aikido ; Socket compte 19 versions), totalisant selon Aikido plus de 2 milliards de téléchargements hebdomadaires, remplaçaient dans le navigateur des adresses de portefeuilles en interceptant fetch, XMLHttpRequest et window.ethereum.

3. 3
   Ver se propageant via des tokens volésShai-Hulud – septembre 2025

   Un ver auto-réplicant injectait des scripts post-install, recherchait des secrets avec TruffleHog, dans les variables d’environnement et les métadonnées cloud, et publiait d’autres paquets à l’aide de tokens npm dérobés. GitHub a supprimé plus de 500 paquets compromis ; Wiz fait remonter la campagne à des identifiants issus de s1ngularity.

4. 4
   preinstall et porte dérobée de runnerShai-Hulud 2.0 – à partir du 24 novembre 2025

   La deuxième vague se déclenchait dès la phase preinstall, déguisée en installateur Bun, enregistrait les hôtes infectés comme runners GitHub auto-hébergés et a créé, selon Wiz, plus de 25 000 dépôts malveillants. Lorsqu’elle ne parvenait ni à voler des identifiants ni à exfiltrer des données, elle tentait, selon Unit 42, de détruire le répertoire personnel.

5. 5
   Poste du mainteneur compromisaxios – 31 mars 2026

   Après une ingénierie sociale et l’infection de son poste par un RAT (cheval de Troie d’accès à distance), axios 1.14.1 et 0.30.4 ont été publiés via le compte personnel du mainteneur principal, avec une dépendance supplémentaire qui chargeait en plusieurs étapes d’autres logiciels malveillants, RAT compris – pendant environ trois heures. Dans son alerte du 20 avril 2026, la CISA a expressément recommandé ignore-scripts=true et min-release-age=7 (jours) dans le .npmrc ainsi qu’une MFA résistante à l’hameçonnage.

6. 6
   Provenance valide, l’agent comme lieu de persistanceTanStack / Mini Shai-Hulud – 11 mai 2026

   Via un workflow pull_request_target et un cache Actions empoisonné, des attaquants ont lu dans la mémoire du runner le token OIDC destiné au Trusted Publishing et publié 84 versions malveillantes de 42 paquets @tanstack – avec une provenance SLSA Build Level 3 valide (StepSecurity). Pour assurer sa persistance, le logiciel malveillant écrivait dans .claude/settings.json un hook SessionStart qui exécute node .vscode/setup.mjs à chaque démarrage de Claude Code, ainsi qu’une tâche VS Code avec runOn: folderOpen.

Deux leçons

Premièrement : la provenance – la preuve signée indiquant de quel dépôt et de quel build provient un paquet – atteste l’origine, pas l’innocuité. En substance, selon StepSecurity, la provenance SLSA confirme quel pipeline a produit un artefact – et non s’il s’est comporté comme prévu. Dans le cas Red Hat « Miasma », 32 paquets manipulés portaient eux aussi des signatures valides, car les attaquants avaient utilisé la voie de publication OIDC légitime (Microsoft, 2 juin 2026). La documentation de npm précise elle-même que la provenance ne garantit pas un contenu exempt de code malveillant.

Deuxièmement : les tokens sont la monnaie de la propagation. La plupart de ces charges utiles recherchaient des identifiants npm, GitHub, cloud ou d’API de LLM et utilisaient des droits de publication pour la vague suivante. Appréciation de VamiSec : chaque session d’agent dans laquelle des tokens en clair, des profils cloud ou des droits d’écriture sur un registre sont accessibles est un point de départ possible d’une telle vague. Mini Shai-Hulud montre en outre que la configuration de l’agent elle-même devient un lieu de persistance.

Dans son cadre du 28 juillet 2026, HiddenLayer place une thèse au centre : la surface d’attaque essentielle d’un agent de codage n’est pas le modèle, mais son harness – prompts, outils, skills, serveurs MCP et logique d’orchestration autour du modèle. HiddenLayer voit la racine des attaques dans une confiance mal placée. Dès le 16 juillet 2026, l’entreprise avait classé chaque source lue par un agent comme point d’entrée possible d’une injection de prompt indirecte.

Classes d’attaques documentées

L’OWASP classe les hallucinations de paquets elles-mêmes sous LLM09 Misinformation (« Unsafe Code Generation »), et non sous LLM03 Supply Chain. Dans la liste Agentic, ASI05 couvre le cas où des paquets installés sans vérification exécutent du code malveillant lors de l’installation ou de l’import ; ASI04 recommande entre autres de rechercher les typosquats.

IDEsaster (Ari Marzouk) décrit pour Copilot, Cursor, Windsurf, Claude Code et d’autres IDE d’IA une nouvelle chaîne : injection de prompt → outils → fonctions de base de l’IDE, comme les schémas JSON distants ou des paramètres d’espace de travail écrasés. S’y ajoutent des failles dans la logique d’approbation et de sandbox des CLI d’agents, par exemple une boîte de dialogue de confirmation contournable dans Claude Code (CVE-2025-54795, CVSS 4.0 : 8,7) ou une évasion de sandbox via un répertoire de travail imposé par le modèle dans Codex CLI (CVE-2025-59532, CVSS 4.0 : 8,6).

Idée directrice : la sécurité hors du modèle

La plupart des cas partagent une même structure : le modèle a fait ce que son contexte suggérait. Là où les éditeurs ont apporté des corrections, ce n’était pas au niveau du modèle, mais dans le harness – par une nouvelle approbation des configurations MCP modifiées, la boîte de dialogue de confiance avant toute exécution, la vérification canonique des chemins ou des listes d’autorisation plus restrictives. HiddenLayer intitule d’ailleurs sa couche de surveillance ainsi : la sécurité doit exister en dehors du modèle. Appréciation de VamiSec : traitez les fichiers de règles, les configurations MCP, les hooks et les skills comme du code exécutable – avec revue, gestion de versions et approbation – et toute source lue par l’agent comme une entrée non fiable.

Ce que recommande HiddenLayer (pratique)

HiddenLayer intitule la première couche de son cadre du 28 juillet 2026 « Understand Every Trust Relationship » – comprendre chaque relation de confiance. Elle porte sur quatre objets :

• Tous les agents, modèles, harnesses, outils, serveurs MCP et skills utilisés – y compris, expressément, l’IA fantôme (shadow AI).
• Les autorisations de chaque agent et les systèmes qu’il peut atteindre.
• L’origine et l’intégrité des outils, des skills et des services externes.
• Les interactions à l’exécution entre agents, outils, dépôts et systèmes externes.

L’origine et l’intégrité ne sont pas une simple formalité : les serveurs MCP distants peuvent changer sans que l’organisation s’en aperçoive (HiddenLayer, 16 juillet 2026). Un inventaire qui ne contient que des noms devient donc obsolète sans que personne ne le remarque. Contre l’IA fantôme, le BSI et l’ANSSI recommandent des comptes d’entreprise contrôlés plutôt que des accès privés, ainsi que des règles claires sur les outils pouvant être utilisés avec quelles données. Dans sa recommandation juridiquement non contraignante sur les gestionnaires de paquets du 10 mars 2026, l’ENISA conseille en outre d’assurer la visibilité sur tous les paquets que sélectionnent les outils d’IA.

Mise en œuvre : nomenclature des agents et SBOM (recommandation VamiSec)

Nous recommandons de tenir l’inventaire sous la forme d’une nomenclature des agents (AI-BOM) : un répertoire lisible par machine qui consigne, pour chaque agent, l’outil et sa version, le modèle et le fournisseur, le mode de fonctionnement, les serveurs MCP et skills connectés avec leur version ou leur hachage, les fichiers de règles ainsi que l’identité utilisée. S’y ajoute la SBOM (Software Bill of Materials, nomenclature de tous les composants logiciels) de chaque release. En cas d’incident, les deux répondent à la même question : où se trouve le composant concerné ?

La profondeur de la SBOM mérite de la précision. À l’annexe I, partie II, point 1, le CRA exige une SBOM dans un format courant et lisible par machine couvrant au minimum les dépendances de premier niveau – applicable à partir du 11 décembre 2027 ; il n’impose actuellement aucun format particulier. La BSI TR-03183-2 (version 2.1.0) exige en revanche, pour les SBOM conformes à la TR, une résolution récursive et cite CycloneDX à partir de 1.6 ou SPDX à partir de 3.0.1. Du code malveillant peut arriver par des dépendances transitives : la version malveillante axios 1.14.1 ajoutait la dépendance plain-crypto-js, qui chargeait d’autres étapes malveillantes (CISA, 20 avril 2026). Nous recommandons donc la SBOM récursive comme standard de travail – en tant que bonne pratique, et non comme obligation du CRA. Selon l’ENISA (SBOM Adoption State of Play, juin 2026), 24 % des répondants ont besoin d’une analyse en profondeur complète, mais seuls 14 % l’obtiennent.

Lien avec la chaîne d’attaque

La visibilité n’est pas un point de rupture, mais la condition de tous les autres. Elle complique l’étape 03 (Adoption), car les nouveaux paquets, serveurs MCP et skills sont repérés. Sans inventaire, les listes d’autorisation, l’isolation et la surveillance ne peuvent pas être appliquées de manière exhaustive. Après un incident, elle limite l’étape 07 (Propagation) : les dépôts, hôtes et tokens concernés peuvent être nommés immédiatement, au lieu de devoir d’abord être recherchés.

Ancrage réglementaire : les entités financières soumises au cadre DORA complet doivent, en vertu de l’art. 10(2)(d) du règlement délégué (UE) 2024/1774 (RTS sur la gestion du risque lié aux TIC), suivre quelles bibliothèques tierces et open source utilisent les services TIC soutenant des fonctions critiques ou importantes – y compris leurs versions et mises à jour. Le Grundschutz++ du BSI prévoit, en tant qu’exigence SOLLTE (« devrait »), de documenter les composants par une SBOM avant la release (DEV.4.3, avec renvoi à la TR-03183-2).

Ce que recommande HiddenLayer (pratique)

Sous « Limit the Impact of Compromise », HiddenLayer cite cinq mesures : le moindre privilège par défaut, l’approbation humaine pour les actions lourdes de conséquences, l’accès aux seuls outils, serveurs MCP et skills approuvés, la limitation des connexions réseau sortantes inutiles ainsi que l’examen des prompts système et des configurations par défaut avant le déploiement. L’OWASP Top 10 for Agentic Applications 2026 étend le moindre privilège à la « Least Agency » : pas d’autonomie là où elle n’est pas nécessaire. La ligne directrice publiée le 1er mai 2026 par la CISA, la NSA et des autorités partenaires des Five Eyes recommande elle aussi de ne pas accorder aux agents un large accès aux données sensibles et aux systèmes critiques.

Des vulnérabilités documentées montrent que les valeurs par défaut ne sont pas automatiquement sûres : avant la version 1.0.4, Claude Code contenait une liste trop large de commandes « sûres », par laquelle des contenus de fichiers pouvaient être exfiltrés sans confirmation (CVE-2025-55284, CVSS 4.0 : 7,1). Chez GitHub Copilot (VS Code/Visual Studio), l’obligation de confirmation pouvait être entièrement désactivée par injection de prompt (CVE-2025-53773, voir chapitre 5).

Mise en œuvre en six étapes (recommandation VamiSec)

1. 1
   Environnement d’exécutionIsoler

   Les agents disposant d’un accès au terminal et les builds s’exécutent dans des conteneurs, des devcontainers ou des VM – sans identifiants de l’hôte montés, sans agent SSH ni profils cloud. Si du code malveillant s’exécute, il trouve aussi peu que possible qui vaille la peine d’être volé.

2. 2
   IdentitéAttribuer une identité propre

   L’agent ne travaille pas avec les tokens personnels de la développeuse, mais avec une identité propre aux droits étroitement définis : uniquement les dépôts et scopes dont la tâche a besoin, aucun droit de publication.

3. 3
   TokensIdentifiants à courte durée de vie

   Publier ses propres paquets via Trusted Publishing (OIDC) plutôt qu’avec des tokens enregistrés – disponible pour tous sur npm depuis le 31 juillet 2025, à partir de npm CLI 11.5.1. Là où des tokens subsistent, choisir la durée de validité la plus courte possible en pratique.

4. 4
   Outils, MCP, skillsImposer des listes d’autorisation

   Seuls les outils, serveurs MCP et skills approuvés peuvent être chargés ; les paquets passent exclusivement par le proxy interne (voir Hygiène des dépendances).

5. 5
   RéseauLimiter l’egress

   Trafic sortant uniquement vers des destinations approuvées. Même des outils anodins transportent des données : HiddenLayer a montré en 2025 comment une clé SSH a été exfiltrée via l’URL d’image d’un diagramme.

6. 6
   ConfigurationImposer les paramètres de manière centralisée

   Approbation automatique désactivée ; approbation requise pour les installations, les commandes réseau et les accès en écriture à la configuration de l’agent. Bloquer les options comme --dangerously-skip-permissions, --yolo ou --trust-all-tools – selon Wiz, le logiciel malveillant s1ngularity appelait les CLI d’IA locales précisément avec celles-ci. Là où l’outil prend en charge des politiques gérées de manière centralisée, celles-ci devraient primer sur les paramètres issus du dépôt.

L’approbation humaine n’est efficace que si la personne voit ce qu’elle approuve. Dans la démo de tool poisoning d’Invariant Labs, la boîte de dialogue de confirmation n’affichait pas les entrées complètes. Le BSI recommande expressément une confirmation par l’utilisateur avant qu’un LLM n’exécute des fonctions (Evasion Attacks on LLMs, 6 novembre 2025). Nous recommandons des boîtes de dialogue qui affichent intégralement la commande, le nom du paquet et la destination – et des approbations peu nombreuses mais prises au sérieux plutôt que des confirmations permanentes.

Lien avec la chaîne d’attaque

Cette couche fournit le plus grand nombre de points de rupture : l’isolation sans secrets de l’hôte interrompt l’étape 06 (Accès), le contrôle de l’egress l’étape 07 (Propagation), la liste d’autorisation dans le proxy l’étape 04 (Résolution). L’approbation humaine complique l’étape 03 (Adoption). Des tokens à courte durée de vie et aux droits étroits limitent la portée d’identifiants volés.

Preuves pour les auditeurs

• Configuration imposée de manière centralisée pour chaque agent (approbation automatique, obligations d’approbation, options bloquées) avec historique des modifications.
• Définition de l’image ou du devcontainer sans identifiants montés, accompagnée des règles d’egress.
• Inventaire des tokens avec identité, scope et date d’expiration ; Trusted Publishing pour les paquets propres.
• Échantillons tirés des journaux d’approbation.

Ancrage réglementaire : pour les entités essentielles et importantes, l’art. 21(2)(e) NIS2 et le § 30, al. 2, phrase 2, n° 5 du BSIG (loi allemande sur le BSI) exigent des mesures de sécurité dans l’acquisition, le développement et la maintenance. Le règlement d’exécution (UE) 2024/2690 impose, pour les types d’entités qui y sont mentionnés, par exemple les fournisseurs de services cloud et de services gérés, des exigences de sécurité applicables aux environnements de développement (annexe, point 6.2). Les entités financières soumises au cadre DORA complet doivent séparer l’approbation des modifications de leur demande et de leur mise en œuvre (art. 17(1) RTS 2024/1774 relatif à l’art. 9(4)(e) DORA) – un agent qui approuve ses propres modifications n’est guère compatible avec cette exigence (appréciation de VamiSec).

Ce que recommande HiddenLayer (pratique)

• Tester les agents avant le déploiement avec des entrées adverses (red teaming).
• Vérifier les actions proposées avant leur exécution.
• Examiner les outils et skills de tiers – y compris les métadonnées cachées.
• Approuver des versions précises au lieu de faire durablement confiance à « latest ».

Le dernier point vise le rug pull : un serveur MCP modifie la description de ses outils après avoir été approuvé (Invariant Labs, 1er avril 2025). MCPoison a montré le même schéma au niveau de la configuration : après la première approbation, un commit suffisait pour remplacer la commande d’une entrée MCP sans nouvelle demande de confirmation (CVE-2025-54136, voir chapitre 5). Selon The Register, le paquet npm non officiel postmark-mcp a livré 15 versions anodines avant que la version 1.0.16 n’envoie chaque e-mail sortant en copie cachée à une adresse tierce.

Les métadonnées cachées constituent le deuxième axe. Les instructions figurant dans les descriptions d’outils sont invisibles pour les utilisateurs, mais le modèle les lit (Invariant Labs) ; les fichiers de règles peuvent contenir des instructions sous forme de caractères Unicode invisibles (Pillar Security, 18 mars 2025). Parmi 3 984 Agent Skills examinés par Snyk, 76 étaient avérés malveillants (5 février 2026, détails au chapitre 5).

Mise en œuvre : approbation par composant (recommandation VamiSec)

Le code généré par IA ne bénéficie d’aucun régime particulier. Le BSI et l’ANSSI constatent que les assistants de codage IA ne remplacent pas les développeurs expérimentés et que les gains de productivité doivent être compensés par davantage d’assurance qualité (4 octobre 2024). Les fichiers d’instructions comme AGENTS.md aident, mais ne constituent pas un contrôle. Le guide de l’OpenSSF pour les assistants de code (1er août 2025) recommande l’instruction de n’ajouter aucune dépendance susceptible d’être malveillante ou hallucinée. Cela peut réduire le risque – mais le modèle peut ignorer la règle, et des instructions de skill d’apparence anodine peuvent même renforcer les hallucinations de paquets (Hsu et al., accepté pour EMNLP 2026).

Red teaming avant le déploiement

1. 1
   Définir les scénarios

   Des tâches qui provoquent des suggestions de paquets ; des README, issues et descriptions d’outils préparés avec des instructions cachées ; des tentatives de modifier les paramètres de l’agent ou de lire des fichiers d’identifiants.

2. 2
   Exécuter dans la configuration cible

   Avec exactement le modèle, le harness, les serveurs MCP et les skills qui doivent être déployés – dans un environnement isolé.

3. 3
   Mesurer

   À quelle fréquence l’agent invente-t-il des paquets ? Suit-il des instructions injectées ? L’approbation, le proxy et l’isolation de la couche 2 sont-ils efficaces ?

4. 4
   Répéter

   À chaque changement de modèle, de version d’outil ou d’intégration, et comme test de non-régression après des incidents.

Lien avec la chaîne d’attaque : la validation complique les étapes 01 (Invention) et 03 (Adoption), car les noms inventés sont repérés lors des tests et des revues. L’approbation des versions empêche qu’un composant modifié en silence soit chargé à l’étape 04 (Résolution). Preuves pour les auditeurs : rapport de red team pour chaque configuration d’agent, liste d’autorisation avec versions et hachages, comptes rendus de revue des nouvelles dépendances, preuves de test pour le code généré par IA.

Ancrage réglementaire : pour les entités financières soumises au cadre DORA complet, l’art. 16 du RTS 2024/1774 exige des revues de code source avec tests statiques et dynamiques (par. 3), des tests de sécurité des progiciels au plus tard lors de la phase d’intégration (par. 4) et – dans la mesure du possible – l’analyse et le test du code source open source avant la mise en production (par. 8). Le CRA exige des fabricants, à partir du 11 décembre 2027, des tests et examens de sécurité efficaces et réguliers (annexe I, partie II, point 3).

HiddenLayer justifie la quatrième couche en quelques mots : les modèles de langage sont conçus pour suivre des instructions – pas pour faire respecter des politiques de sécurité (en substance). Un contrôle qui ne figure que dans le prompt tombe à la première injection de prompt réussie. La surveillance s’appuie donc sur le système d’exploitation, le réseau, le pipeline et le harness. L’OWASP Top 10 for Agentic Applications qualifie une forte observabilité de « non négociable ».

Ce que HiddenLayer veut observer (pratique)

• Mouvements de données sensibles
• Utilisation des outils et opérations sur les fichiers
• Tentatives d’élévation de privilèges
• Activité d’IA fantôme
• Utilisation des API et consommation de calcul anormale

Pistes de détection tirées d’incidents réels (recommandation VamiSec)

Les campagnes des derniers mois fournissent des schémas concrets. Selon StepSecurity, la vague Mini Shai-Hulud autour de TanStack s’est ancrée via un hook SessionStart de Claude Code et une tâche VS Code (détails au chapitre 4). Selon Socket, SANDWORM_MODE inscrivait son propre serveur MCP dans la configuration de Claude Code, de Cursor et d’autres outils. Selon Microsoft, Miasma maintenait un canal d’exfiltration dormant via api.anthropic.com ; selon Snyk, le domaine d’exfiltration des releases de litellm avait été enregistré la veille. Plusieurs vagues lançaient Bun comme environnement d’exécution – un moyen de contourner une surveillance centrée sur Node.

Télémétrie via les hooks des agents

Plusieurs agents de codage proposent des interfaces de hooks qui lancent des programmes propres lors des appels d’outils. Nous recommandons de les utiliser pour journaliser de manière centralisée les appels d’outils, les commandes shell et les accès aux fichiers, et pour examiner les appels risqués avant leur exécution. Mais cette même interface est une voie de persistance, comme le montre la vague TanStack ; dans Claude Code, des hooks issus de fichiers de projet se sont un temps exécutés sans consentement (Check Point, corrigé le 26 août 2025). Les hooks relèvent donc de la configuration gérée de manière centralisée – toute modification les concernant est en soi un signal d’alerte.

Lien avec la chaîne d’attaque : la surveillance n’interrompt de manière fiable aucune étape, mais elle réduit la durée pendant laquelle les étapes 05 (Exécution), 06 (Accès) et 07 (Propagation) passent inaperçues. Les incidents montrent à quel point les fenêtres sont courtes : les versions malveillantes de TanStack ont été marquées comme obsolètes au bout d’environ 1,7 heure, les versions d’axios supprimées au bout d’environ trois heures. Nous en concluons que la détection propre doit réagir en heures, pas en jours.

Ancrage réglementaire : le règlement d’exécution (UE) 2024/2690 exige, pour les types d’entités qui y sont mentionnés, une protection contre les logiciels malveillants et non autorisés, y compris des mesures de détection (annexe, point 6.9) ; pour les autres entités NIS2, il sert de référence. La ligne directrice des Five Eyes sur l’IA agentique (1er mai 2026) mentionne expressément la surveillance continue.

Ce que recommande HiddenLayer (pratique)

Sous « Security Requires Ownership », HiddenLayer cite quatre points : une personne responsable (owner) pour chaque agent utilisé en production, l’intégration des agents de codage dans les modèles de menaces et les programmes de gouvernance de l’IA existants, des procédures de réponse aux incidents propres à l’IA agentique et le réexamen régulier des autorisations et des intégrations de confiance. La ligne directrice des Five Eyes du 1er mai 2026 recommande elle aussi d’intégrer les risques de l’IA agentique dans les cadres existants et de pratiquer la modélisation des menaces.

Pour les entités NIS2, c’est une tâche de direction. Les organes de direction doivent approuver les mesures de gestion des risques, superviser leur mise en œuvre et peuvent être tenus responsables (art. 20(1) et (2) NIS2). En Allemagne, le § 38 BSIG oblige les organes de direction des entités essentielles et importantes à assurer la mise en œuvre, la supervision et des formations régulières ; la responsabilité est régie par le droit des sociétés. Une politique relative aux outils de codage IA devrait donc être approuvée par la direction.

Composants d’une politique relative aux outils de codage IA (recommandation VamiSec)

• Outils, modèles et modes de fonctionnement autorisés ; utilisation uniquement via des comptes d’entreprise.
• Classes de données : quelles informations peuvent être saisies dans quel outil.
• Niveaux d’autonomie : ce qu’un agent peut faire seul, ce qui nécessite une approbation, ce qui est interdit.
• Règles relatives aux paquets : approvisionnement uniquement via le proxy interne, délai de carence, aucun script d’installation sans approbation.
• Processus d’approbation des serveurs MCP, skills et fichiers de règles, lié à une version ou à un hachage.
• Principe des quatre yeux pour les merges – y compris pour les pull requests d’agents.
• Journalisation, procédure d’exception et recertification des droits et des intégrations, par exemple tous les six mois.
• Formation : depuis le Digital Omnibus (règlement (UE) 2026/1744, en vigueur depuis le 27 juillet 2026), l’art. 4 de l’AI Act exige des fournisseurs et des déployeurs des mesures de soutien à la maîtrise de l’IA, mais pas un niveau garanti.

Dans le modèle de menaces, l’agent apparaît comme un acteur à part entière, doté de droits ; les fichiers de règles, les skills, les serveurs MCP et les sources de paquets sont des frontières de confiance. Le projet de l’ENISA sur le développement logiciel assisté par l’IA (v0.4, septembre 2026) décrit à cet effet des menaces STRIDE comme l’introduction subreptice de paquets, de skills ou de fichiers d’instructions malveillants.

Playbook de réponse aux incidents : paquet malveillant installé ou agent compromis

1. 1
   EndiguerIsoler

   Déconnecter du réseau les hôtes, conteneurs et runners concernés, mettre fin aux sessions d’agents en cours, suspendre les pipelines utilisant le paquet. Préserver les traces avant toute réinstallation.

2. 2
   EndiguerRenouveler les identifiants

   Tous les secrets accessibles : tokens de registre, tokens de la plateforme Git, accès cloud et Vault, clés d’API de modèles. Après Shai-Hulud, la CISA a expressément conseillé leur rotation. Sans l’inventaire des tokens des couches 1 et 2, cette étape reste lacunaire.

3. 3
   AssainirVérifier les lockfiles et les caches

   Quels dépôts, lockfiles, caches de paquets et de CI contiennent les versions concernées ? Chez TanStack, l’attaque est passée par un cache GitHub Actions empoisonné – les caches font partie de l’assainissement.

4. 4
   AssainirRechercher la persistance dans la configuration de l’agent

   Hooks et entrées MCP dans les configurations utilisateur et projet, tâches VS Code avec runOn: folderOpen, nouveaux runners auto-hébergés et workflows, fichiers .pth. En cas de doute, réinstaller plutôt que nettoyer.

5. 5
   NotifierVérifier les obligations de notification

   Depuis le 11 septembre 2026, les fabricants soumis au CRA notifient les vulnérabilités activement exploitées de leurs produits via la plateforme unique de signalement (Single Reporting Platform), simultanément au CSIRT coordinateur et à l’ENISA : alerte précoce sous 24 heures, notification sous 72 heures, rapport final au plus tard 14 jours après la mise à disposition d’une mesure corrective. Pertinent si du code malveillant a pu se retrouver dans un produit livré (appréciation de VamiSec, à vérifier juridiquement au cas par cas). Les entités NIS2 et DORA vérifient parallèlement leurs propres circuits de notification.

6. 6
   ApprendreRetour d’expérience

   Documenter la cause, l’étape atteinte et les points de rupture manquants, recertifier les droits et les intégrations, informer les opérateurs de registre et les mainteneurs.

Lien avec la chaîne d’attaque : la gouvernance complique l’étape 07 (Propagation), car il est clarifié à l’avance qui renouvelle quels tokens, qui bloque quoi et qui notifie qui. Elle maintient en même temps les autres couches à jour – sans recertification, les droits et les intégrations s’étendent insidieusement.

Pour l’approvisionnement en paquets, le délai de carence – un âge minimal des nouvelles versions avant leur installation – et le blocage des scripts d’installation portent l’essentiel de la charge. Faites attention aux unités.

Deux limites s’y ajoutent. Premièrement, un délai de carence intercepte les versions malveillantes qui, selon pnpm, sont le plus souvent détectées et supprimées en moins d’une heure – mais pas un nom halluciné qu’un attaquant occupe tôt avant d’attendre. Deuxièmement, ignore-scripts est incomplet : les dépendances Git peuvent exécuter du code via leur propre .npmrc (contre-mesure : --allow-git=none à partir de npm 11.10.0), les dépendances URL comme dans le cas PhantomRaven nécessitent --allow-remote=none (à partir de 11.15.0), et aucun blocage de scripts ne couvre le code exécuté à l’import.

Configuration pour les builds et les agents (recommandation VamiSec)

# Builds CI et agents : uniquement via le proxy interne (espace réservé)
registry=https://registry.intern.example/
# aucun script de cycle de vie
ignore-scripts=true
# uniquement des versions de plus de 7 jours (à partir de npm 11.10.0)
min-release-age=7

# pyproject.toml : uniquement des versions de plus de 7 jours (à partir de uv 0.9.17)
[tool.uv]
exclude-newer = "7 days"
# Exceptions par paquet : exclude-newer-package

# pip à partir de 26.1 : durée en jours, plus hachages obligatoires
pip install --require-hashes --uploaded-prior-to P7D -r requirements.txt

Exempter les mises à jour de sécurité : un délai de carence ne doit pas retarder les correctifs. Dependabot et Renovate le contournent par défaut pour les mises à jour de sécurité, et les gestionnaires de paquets connaissent des listes d’exceptions (min-release-age-exclude, minimumReleaseAgeExclude, minimumReleaseAgeExcludes, exclude-newer-package). PyPI conseille de coupler les délais de carence à des analyses de vulnérabilités.

Lockfiles, revue, proxy, provenance

Dans la CI et les environnements d’agents, n’installer que de manière reproductible : npm ci, pnpm install --frozen-lockfile, pip avec --require-hashes. Dans le cas LiteLLM, selon PyPI, environ 40 à 50 % des installations effectuées pendant la fenêtre d’attaque n’étaient pas épinglées. L’OWASP décrit le cas d’un agent qui régénère un lockfile à partir de spécifications non épinglées et récupère une version mineure compromise – toute nouvelle dépendance et toute modification du lockfile nécessitent donc une approbation nominative lors de la revue des dépendances. Techniquement, un proxy de registre interne doté d’une liste d’autorisation permet de l’imposer ; le BSI et l’ANSSI recommandent une liste d’autorisation des paquets permis. Une simple vérification d’existence ne suffit pas : l’attaquant peut avoir enregistré le nom au préalable (Spracklen et al.).

npm audit signatures vérifie les signatures du registre et les attestations de provenance (à partir de npm 9.5.0) ; depuis le 14 novembre 2024, PyPI prend en charge les attestations selon la PEP 740, que pip et uv ne vérifient pas automatiquement selon Trail of Bits. Les deux attestent l’origine, pas l’innocuité : les paquets malveillants de TanStack et de Miasma portaient eux aussi une provenance ou des signatures valides (voir chapitre 4). C’est utile comme contrôle supplémentaire, mais inadapté comme unique critère d’approbation.

Ancrage réglementaire : la recommandation juridiquement non contraignante de l’ENISA sur les gestionnaires de paquets (10 mars 2026) préconise des registres officiels et vérifiables, des lockfiles et des contrôles d’intégrité dans la CI/CD. Le Grundschutz++ prévoit, en tant qu’exigences SOLLTE, d’interdire les artefacts externes provenant de sources inconnues, de tester leur intégrité et de vérifier les mises à jour de sécurité (DEV.4.2, DEV.4.4, DEV.4.5) ; le Kompendium 2023 exige des sources fiables et l’examen des composants inconnus (CON.8.A6, CON.8.A20). L’art. 21(2)(d) NIS2 et le § 30, al. 2, phrase 2, n° 4 BSIG exigent la sécurité de la chaîne d’approvisionnement ; à partir du 11 décembre 2027, les fabricants soumis au CRA sont tenus à l’obligation de diligence pour les composants tiers en vertu de l’art. 13(5) – expressément aussi pour l’open source.

Le CRA, NIS2 et DORA adoptent une approche similaire : est responsable celui qui intègre le composant ou exploite le système (appréciation de VamiSec). Pour le Cyber Resilience Act (CRA), l’exemple 34 des lignes directrices de la Commission C(2026) 5252 du 27 juillet 2026 l’illustre : un développeur individuel qui publie une bibliothèque open source libre dans un dépôt public de paquets, ainsi que le dépôt lui-même, n’ont aucune obligation au titre du CRA. À partir du 11 décembre 2027, l’obligation de diligence prévue à l’art. 13(5) incombe au fabricant intégrateur, selon une approche fondée sur les risques conformément au considérant 34. Les lignes directrices ne sont pas contraignantes. Que ce soit un humain ou un agent qui a choisi le paquet n’y change rien (appréciation de VamiSec).

Cyber Resilience Act : obligation de notification depuis 2026, obligation de diligence à partir de 2027

• Obligation depuis le 11 septembre 2026 (art. 14(1)–(2)) : notifier les vulnérabilités activement exploitées via la Single Reporting Platform (SRP) au CSIRT et à l’ENISA — alerte précoce sous 24 h, notification sous 72 h, rapport final au plus tard 14 jours après la mise à disposition d’une mesure corrective ; y compris pour les produits déjà sur le marché.
• Obligation à partir du 11 décembre 2027 : diligence à l’égard des composants tiers, y compris les logiciels libres et open source (art. 13(5)), signalement des vulnérabilités des composants à leur fabricant ou mainteneur (par. 6), aucune livraison de produits présentant des vulnérabilités exploitables connues (annexe I, partie I, point 2, a)).
• SBOM : l’annexe I, partie II, point 1, exige au minimum les dépendances de premier niveau ; seule la BSI TR-03183-2 v2.1.0 exige une résolution récursive — bonne pratique, pas une obligation du CRA. Le CRA n’impose aucun format tel que CycloneDX ou SPDX ; aucun acte d’exécution à ce sujet (art. 13(24), disposition facultative) ne figure dans la liste de la Commission (état : 27 juillet 2026).
• Amendes (art. 64(2)) : en cas d’infraction à l’annexe I, à l’art. 13 ou 14, jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu.

NIS2 et BSIG : chaîne d’approvisionnement et développement comme mesures minimales

NIS2 exige la sécurité de la chaîne d’approvisionnement (art. 21(2)(d)) ainsi que la sécurité dans l’acquisition, le développement et la maintenance (point e)). L’art. 21(3), selon lequel les entités tiennent également compte, dans le choix des mesures relatives à la chaîne d’approvisionnement, des procédures de développement sécurisé de leurs fournisseurs directs, ne figure pas littéralement dans le BSIG ; il peut être mobilisé par le biais d’une interprétation conforme à la directive. En Allemagne, le § 30, al. 2, phrase 2, n° 4 et 5 BSIG s’applique depuis le 6 décembre 2025 ; l’organe de direction met en œuvre, supervise et engage sa responsabilité en cas de manquement fautif selon le droit des sociétés (§ 38 BSIG, art. 20 NIS2). Pour des mesures manquantes ou non documentées, le § 65 prévoit jusqu’à 10 millions d’euros (entités essentielles) ou 7 millions d’euros (entités importantes) et, pour un chiffre d’affaires total supérieur à 500 millions d’euros, jusqu’à 2 % ou 1,4 % du chiffre d’affaires total. Le règlement d’exécution (UE) 2024/2690 n’est contraignant que pour les types d’entités énumérés à son art. 1, comme les fournisseurs de services cloud, de centres de données et de services gérés ; pour toutes les autres, il sert de référence.

DORA : les ancrages précis se trouvent dans le RTS

Depuis le 17 janvier 2025, DORA exige que les modifications des systèmes de TIC soient enregistrées, testées, évaluées, approuvées, mises en œuvre et vérifiées (art. 9(4)(e)), et laisse aux entités financières l’entière responsabilité en matière de services TIC (art. 28(1)). Pour les bibliothèques obtenues librement, le RTS 2024/1774 est plus précis (cadre complet, titre II) : suivre les bibliothèques utilisées pour des fonctions critiques ou importantes (art. 10(2)(d)), revues de code avec tests statiques et dynamiques (art. 16(3)), tester les progiciels au plus tard lors de l’intégration (par. 4), protéger l’intégrité du code source (par. 7), examiner le code open source avant la mise en production, dans la mesure du possible (par. 8), séparer l’approbation et la mise en œuvre des modifications (art. 17(1)). Un agent qui fusionne ses propres pull requests ne cadre pas avec ces exigences (appréciation de VamiSec).

AI Act et responsabilité du fait des produits

Au sens de l’AI Act, un assistant de codage n’est généralement pas un système à haut risque, car le développement logiciel ne figure pas à l’annexe III. Pour les entreprises déployeuses, l’art. 4 demeure : depuis le Digital Omnibus (règlement (UE) 2026/1744, en vigueur depuis le 27 juillet 2026), elles doivent prendre des mesures de soutien à la maîtrise de l’IA, sans devoir garantir un niveau. Les obligations relatives aux modèles d’IA à usage général (GPAI) incombent aux fournisseurs de modèles, pas aux utilisateurs. En vertu de la directive sur la responsabilité du fait des produits (UE) 2024/2853, un logiciel est un produit ; pour les produits mis sur le marché après le 9 décembre 2026, le fabricant est responsable envers les personnes physiques y compris des composants défectueux intégrés sous son contrôle, et l’absence de mises à jour de sécurité ne l’exonère pas. La directive produit ses effets via le droit national ; au 8 octobre 2026, la promulgation du projet de loi du gouvernement allemand (BT-Drs. 21/4297) n’a pas pu être vérifiée.

Lignes directrices : une orientation non contraignante

• ENISA, Secure Use of Package Managers (10 mars 2026) : mentionne expressément le slopsquatting et recommande de rendre visibles les paquets choisis par l’IA et de les vérifier automatiquement dans la CI/CD.
• ENISA, AI-assisted software development (projet v0.4, septembre 2026) : paquets hallucinés, skills et fichiers d’instructions introduits subrepticement — pas encore définitif.
• BSI et ANSSI, AI Coding Assistants (4 octobre 2024) : les hallucinations de paquets comme voie vers la « package confusion » ; contrôle de plausibilité, liste d’autorisation, sandboxing.
• BSI Grundschutz++ DEV.4.2 à DEV.4.5 (exigences SOLLTE) : interdire les artefacts provenant de sources peu fiables ou inconnues, y compris les paquets et les modèles ; SBOM, tests d’intégrité. Kompendium 2023 : CON.8.A6, CON.8.A20.

Le plan est une recommandation VamiSec et suit la chaîne d’attaque : vous commencez par créer de la visibilité et combler les lacunes évidentes, puis vous mettez en place des points de rupture aux étapes 04 Résolution et 05 Exécution, et enfin vous rendez les règles contraignantes et mesurables. Le point de départ est un état des lieux honnête, par exemple avec l’autoévaluation proposée sur cette page. Les entreprises réglementées commencent par ce qui s’applique déjà : obligations de notification du CRA depuis le 11 septembre 2026, mesures du BSIG depuis le 6 décembre 2025, DORA depuis le 17 janvier 2025.

Dix indicateurs avec valeurs cibles

Mesurez ce qui interrompt réellement la chaîne, et non le nombre de formations. Les valeurs cibles sont des recommandations VamiSec, pas des seuils réglementaires ; la plupart peuvent être collectées automatiquement à partir des logs du proxy, de la configuration CI et de la configuration centrale des agents. s1ngularity montre à quel point les modes sans confirmation sont risqués : selon Wiz, le logiciel malveillant appelait les CLI d’IA installées localement avec des options comme --dangerously-skip-permissions et --yolo afin d’inventorier les secrets. Faites un rapport trimestriel à l’organe de direction ; dans les entités NIS2, celui-ci doit de toute façon superviser la mise en œuvre des mesures en vertu du § 38 BSIG.

Preuves pour les auditeurs

• Inventaire des outils de codage IA, agents, serveurs MCP et skills avec responsable, version et droits (AI-BOM)
• Politique relative aux outils de codage IA, approuvée par l’organe de direction (art. 20(1) NIS2 ; mise en œuvre et supervision selon le § 38 BSIG)
• Configuration versionnée du proxy, des gestionnaires de paquets, des bots de mise à jour et des règles d’egress — le § 30, al. 1 BSIG exige de documenter le respect des mesures
• Journaux d’approbation des nouvelles dépendances et extensions d’agents issus de l’historique des pull requests, avec approbation humaine des modifications effectuées par les agents (pour les entités financières soumises à DORA : séparation des fonctions selon l’art. 17(1) RTS 2024/1774)
• SBOM par release : au minimum les dépendances de premier niveau (CRA, annexe I, partie II, point 1, à partir du 11 décembre 2027), de préférence récursive selon la BSI TR-03183-2 v2.1.0
• Preuves de test des progiciels au plus tard lors de la phase d’intégration (art. 16(4) RTS 2024/1774) et rapport de red teaming des agents
• Playbook d’incident avec liste de rotation des tokens et circuits de notification selon l’art. 14 CRA (24 h / 72 h / 14 jours), accompagné du compte rendu d’exercice
• Rapport trimestriel d’indicateurs à l’organe de direction