Les outils de développement basés sur l’IA représentent désormais une surface d’attaque pour la supply chain
Chaque développeur de votre équipe collabore avec une IA. GitHub Copilot, Cursor, Claude — ces assistants s’intègrent à l’IDE, lisent le contexte du projet et suggèrent du code. Voilà pour la productivité. Mais côté sécurité, l’alerte est tombée cette semaine : des attaquants ont compris comment détourner cette collaboration en manipulant les fichiers de configuration que les outils d’IA utilisent pour comprendre votre projet.
La chaîne d’attaque TrapDoor commence là où la plupart des contrôles de sécurité des entreprises ne regardent pas : le registre de packages open source. Un développeur installe un package malveillant — souvent un faux très convaincant d’une dépendance légitime — depuis npm, PyPI ou Crates.io. Ce qui distingue TrapDoor, ce n’est pas le vecteur initial. C’est ce que fait le package après l’installation. Au lieu d’exécuter directement une charge utile, le package malveillant modifie le fichier de configuration CLAUDE.md du projet — le document qui explique à l’IA ce que fait le projet, quelles conventions suivre et comment se comporter.
Une fois ce fichier de configuration modifié, l’outil d’IA devient, à son insu, complice de l’attaque. Il lit les instructions modifiées et commence à rediriger les requêtes vers une infrastructure contrôlée par l’attaquant, exfiltrant des identifiants et des variables d’environnement sensibles présentes dans le contexte du projet au moment de la lecture. Le modèle d’IA lui-même n’a pas été compromis. Aucune faille dans GitHub Copilot ou Claude n’a été exploitée. L’attaquant a empoisonné la configuration à laquelle l’IA fait confiance — et l’IA a exécuté exactement ce pour quoi elle était programmée. C’est pourquoi TrapDoor est autant un problème de gouvernance que de sécurité.
5 points clés à retenir
1. Les outils d’IA pour le code peuvent être détournés via la manipulation des fichiers de configuration.
La campagne TrapDoor a distribué 34 packages malveillants sur npm, PyPI et Crates.io ciblant les assistants IA en modifiant des fichiers de configuration de projet comme CLAUDE.md. Une fois modifiés, ces fichiers ont amené les outils d’IA à rediriger les requêtes vers une infrastructure contrôlée par l’attaquant et à exfiltrer des identifiants — sans qu’aucune faille du modèle d’IA ne soit exploitée. L’IA exécutait simplement ce pour quoi elle était configurée. Du point de vue de l’équipe sécurité, rien d’anormal ne s’est produit dans la couche IA. La gouvernance de l’IA doit s’exercer en dessous du modèle.
2. L’accès en lecture non gouverné de l’IA constitue la faille structurelle.
Les outils d’IA pour le code disposent d’un large accès en lecture au contexte du projet — fichiers sources, fichiers de configuration, variables d’environnement, fichiers README — créant un canal de données entre les environnements de développement et l’inférence IA que la plupart des entreprises n’ont jamais explicitement gouverné. Selon le rapport DTEX 2026 Insider Threat, 73 % des organisations craignent que l’utilisation non autorisée de l’IA crée des voies de fuite de données invisibles. TrapDoor a détourné un canal déjà existant.
3. Les attaques sur la supply chain IA suivent un schéma d’escalade documenté.
Le rapport CrowdStrike 2026 Global Threat fait état d’une multiplication par 3 des attaques sur la supply chain IA via des modèles tiers depuis 2022, ainsi qu’une augmentation de 89 % d’une année sur l’autre des activités malveillantes dopées à l’IA. TrapDoor s’inscrit pleinement dans cette tendance — ciblant le même écosystème de développeurs que plusieurs campagnes précédentes ont déjà exploité de façon systématique. L’écosystème npm est d’ailleurs régulièrement cité comme vecteur de compromission récurrent.
4. Les secteurs réglementés font face à une exposition immédiate à la non-conformité, non modélisée.
Les organisations manipulant des CUI, des informations médicales protégées (PHI) ou des données sous contrôle ITAR sont directement exposées à la non-conformité lorsque les assistants IA lisent du contenu sensible sans contrôle d’accès explicite ni gouvernance des flux sortants. Journaliser l’activité a posteriori ne suffit pas à répondre aux exigences de contrôle d’accès du CMMC, de l’HIPAA ou de l’ITAR. Le problème de conformité n’est pas l’apparition de nouvelles obligations réglementaires — c’est l’émergence d’un nouveau moyen de violer des obligations déjà existantes.
5. Les contrôles pré-modèle limitent l’impact en cas de réussite d’une attaque sur la supply chain.
L’application du zéro trust sur le contenu avant qu’un outil n’accède à des données sensibles est la réponse architecturale qui permet de contenir les dégâts en cas de réussite d’une attaque sur la supply chain. La politique d’accès au niveau des données fonctionne indépendamment du fait que la configuration de l’outil d’IA ait été compromise. Un fichier CLAUDE.md modifié peut changer ce que l’IA est censée faire — il ne peut pas élargir les politiques d’accès qui régissent les contenus réellement accessibles à l’IA.
Vous faites confiance à la sécurité de votre organisation. Mais pouvez-vous le prouver ?
Pour en savoir plus :
Le modèle de confiance hérité par les outils d’IA — et exploité par les attaquants
Quand l’IDE d’un développeur intègre un assistant IA, celui-ci reçoit un accès étendu en lecture au contexte du projet. Tout ce que l’IA lit dans le répertoire du projet devient, en pratique, une donnée en transit vers un service externe. Dans la plupart des environnements de développement, ce canal n’est régi que par l’acceptation des conditions d’utilisation de l’outil d’IA par le développeur. Il n’existe aucune politique d’accès explicite définissant quels fichiers l’IA peut lire. Aucun contrôle de flux sortant ne précise quelles données peuvent quitter l’environnement de développement. Aucune alerte ne signale qu’une connexion sortante inattendue est établie vers un point de terminaison inconnu.
92 % des organisations déclarent que l’IA générative a changé la façon dont les employés accèdent et partagent l’information — mais seules 13 % ont intégré l’IA à leur stratégie d’entreprise en incluant la gouvernance, selon le rapport DTEX 2026 Insider Threat. Cet écart — entre adoption de l’IA et gouvernance de l’IA — constitue la surface d’attaque visée par TrapDoor. L’attaque n’a pas créé une voie de fuite invisible. Elle a exploité une faille déjà existante.
Un schéma, pas une anomalie : l’escalade des attaques sur la supply chain IA
Les responsables sécurité qui considèrent TrapDoor comme une attaque isolée devraient revoir leur position. Le rapport CrowdStrike 2026 Global Threat fait état d’une multiplication par 3 des attaques sur la supply chain IA via des modèles tiers depuis 2022, ainsi qu’une augmentation de 89 % d’une année sur l’autre des activités malveillantes dopées à l’IA. CrowdStrike cite spécifiquement l’écosystème npm comme vecteur de compromission récurrent — en s’appuyant sur les packages BeaverTail et le voleur d’informations ShaiHulud pour montrer que les acteurs de la menace ciblent systématiquement la chaîne d’outils des développeurs.
Le rapport prévisionnel Kiteworks 2026 révèle que 63 % des organisations ne peuvent pas imposer de restrictions d’usage aux agents IA, 60 % ne peuvent pas mettre fin à un système IA défaillant et 55 % ne peuvent pas isoler un système IA en cas de comportement inattendu. Dans le contexte de TrapDoor, ces chiffres illustrent les contrôles qui auraient permis de contenir l’attaque : la capacité à définir ce qu’un outil IA a le droit de lire, la possibilité de mettre fin à une session anormale et la faculté d’isoler un outil compromis avant qu’il n’exfiltre des données.
L’exposition à la non-conformité que personne n’a encore modélisée
Pour les organisations des secteurs réglementés, TrapDoor crée une exposition à la non-conformité que peu ont formellement anticipée. Voici les types de données concernés.
CUI dans les bases de code de la défense. Un assistant IA travaillant sur un projet de défense peut avoir accès à des spécifications techniques, des documents de conception et du code source contenant ou référant des CUI. Si la configuration de l’IA est compromise et qu’elle commence à exfiltrer des données vers un point de terminaison contrôlé par l’attaquant, cela constitue une divulgation non autorisée d’informations contrôlées — avec des conséquences directes au regard du CMMC et du DFARS.
Informations médicales protégées (PHI) dans le développement de technologies de santé. Les organismes de santé développant des applications manipulant des données patients disposent souvent de PHI dans leurs environnements de développement pour les tests. Un assistant IA ayant un accès étendu en lecture dans cet environnement accède à des PHI, que cela ait été explicitement prévu ou non lors du déploiement de l’outil.
Données techniques sous contrôle ITAR dans l’aéronautique et la défense. Toute donnée technique soumise à l’exportation qui figure dans le code source, les fichiers de conception ou les fichiers de configuration est soumise à l’ITAR, quel que soit son emplacement. Un outil IA qui lit et exfiltre ces données permet un export non autorisé — sans que le développeur ait explicitement envoyé quoi que ce soit.
Le problème de conformité posé par TrapDoor ne tient pas à de nouvelles obligations réglementaires. Il s’agit d’un nouveau moyen de violer des obligations déjà existantes. Les organisations les plus exposées sont celles qui ont déployé massivement des outils IA pour le code sans aligner ce déploiement sur leurs obligations de conformité existantes.
Ce que signifie vraiment la gouvernance de contenu zéro trust pour les outils d’IA
Appliquer le zéro trust aux outils d’IA a une signification précise : l’accès authentifié à l’outil d’IA ne donne pas automatiquement accès à n’importe quel contenu. Chaque fichier lu par l’IA, chaque configuration chargée, est évalué selon une politique explicite avant d’être autorisé. La question n’est pas de savoir si l’IDE du développeur peut se connecter au service IA. La question est de savoir si le service IA est autorisé à lire un fichier précis, d’une certaine classification, dans le contexte d’un projet donné — et si cet accès est journalisé dans une trace d’audit infalsifiable.
Quand une identité non humaine (ici, les identifiants de service de l’outil IA) est compromise, une architecture de contenu zéro trust change radicalement la donne. Un fichier CLAUDE.md modifié peut changer ce que l’IA est censée faire — mais il ne peut pas élargir les politiques d’accès qui régissent les contenus réellement accessibles à l’IA.
Le serveur Kiteworks Secure MCP et l’AI Data Gateway appliquent ce principe au niveau du contenu : le contenu sensible n’est accessible aux sessions IA que si le rôle de l’utilisateur, l’objectif de la session et la classification du contenu respectent tous les critères de la politique. Chaque accès — humain ou IA — est authentifié, autorisé selon des contrôles d’accès basés sur les attributs, chiffré avec des algorithmes validés FIPS 140-3, et journalisé dans une piste d’audit infalsifiable transmise au SIEM. Le Réseau de données privé Kiteworks étend cette gouvernance à la messagerie électronique, au partage de fichiers, au MFT, au SFTP, aux formulaires web et aux API — une seule politique, un journal d’audit consolidé.
Un principe qui va bien au-delà de TrapDoor
TrapDoor est une campagne précise. Mais le principe qu’elle révèle est général : tout outil qui lit du contenu sensible pose une question de gouvernance du contenu, pas seulement de sécurité. Qu’il s’agisse d’une plateforme de partage de fichiers, d’un client e-mail, d’un assistant IA pour le code ou d’un système de transfert de fichiers géré — la question reste la même. Qui peut accéder à ce contenu ? Dans quelles conditions ? Quels sont les contrôles de flux sortant si cet accès est compromis ?
Pour les équipes sécurité et conformité qui évaluent leur posture, trois questions concrètes s’imposent : premièrement, quels outils IA pour le code sont déployés dans votre environnement de développement et ont-ils été évalués comme des canaux de données — et non comme de simples outils de productivité ? Deuxièmement, à quels contenus ces outils ont-ils accès en lecture, et ces contenus incluent-ils des données soumises à des obligations réglementaires ? Troisièmement, si la configuration d’un outil IA pour le code était compromise aujourd’hui, quels contrôles limiteraient ce que l’IA pourrait lire et où les données pourraient partir ?
Pour en savoir plus sur la protection des données sensibles face aux workflows IA, réservez votre démo sans attendre !
Foire aux questions
Une attaque sur la supply chain visant les outils IA pour le code consiste à insérer du code ou des instructions malveillantes dans un composant de l’écosystème de développement logiciel — comme un package open source — auquel l’outil IA fait confiance. Les packages malveillants de TrapDoor ont modifié des fichiers de configuration que les assistants IA considèrent comme des instructions de référence. Le serveur Kiteworks Secure MCP et l’AI Data Gateway gouvernent les contenus accessibles par les outils IA et les destinations possibles des données — avant qu’une attaque ne puisse réussir, pas après.
Des fichiers de configuration comme CLAUDE.md occupent une place privilégiée dans la hiérarchie de confiance de l’outil IA — ils sont considérés comme des instructions de référence sur le comportement de l’IA. Compromettre un fichier de configuration revient à compromettre les instructions de l’IA sans exploiter de faille technique. L’intégrité de ces fichiers relève donc de la gouvernance, pas seulement de la sécurité — et les cadres de classification des données doivent explicitement inclure les artefacts de configuration des outils IA.
Les sous-traitants de la défense gérant des CUI sous le CMMC, les entreprises technologiques de santé manipulant des informations médicales protégées (PHI) et les sociétés aéronautiques et de défense gérant des données techniques sous contrôle ITAR sont les plus exposées. Le rapport prévisionnel Kiteworks 2026 révèle que 63 % des organisations ne peuvent pas imposer de restrictions d’usage aux agents IA — le contrôle clé qui permet de contenir les attaques de type TrapDoor en cas de compromission de la supply chain.
L’accès authentifié d’un outil IA à un environnement de développement ne donne pas automatiquement accès en lecture à n’importe quel fichier ou type de données. Les politiques d’accès définissent explicitement les contenus accessibles à l’IA, les contrôles de flux sortant déterminent quelles données peuvent quitter l’environnement, et toute connexion sortante anormale déclenche une alerte plutôt qu’une exfiltration réussie. Le serveur Secure MCP applique ce principe au niveau des données, indépendamment du fait que la configuration de l’outil IA ait été modifiée par un attaquant.
TrapDoor s’inscrit dans une escalade documentée — le rapport CrowdStrike 2026 Global Threat recense une multiplication par 3 des attaques sur la supply chain IA depuis 2022. Le schéma : cibler la chaîne d’outils des développeurs, là où les contrôles sont historiquement plus faibles qu’aux frontières de l’entreprise. La gouvernance au niveau des données, avec des contrôles d’accès explicites, une surveillance des flux sortants et des journaux d’audit infalsifiables, permet de contenir ce type d’attaque, quel que soit le registre de packages ou le fichier de configuration utilisé comme point d’entrée.
Ressources complémentaires
- Article de blog
Stratégies Zero‑Trust pour une protection abordable de la vie privée face à l’IA - Article de blog
77 % des organisations échouent à sécuriser les données face à l’IA - eBook
Écart de gouvernance IA : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025 - Article de blog
Il n’existe pas de « –dangerously-skip-permissions » pour vos données - Article de blog
Les régulateurs ne se contentent plus de demander si vous avez une politique IA. Ils veulent des preuves de son efficacité.