Votre IDE est devenu une cible. Et personne ne le défend.

Pendant que les RSSI restent focalisés sur le périmètre cloud et la couverture EDR sur les postes de travail standards, les attaquants ont ouvert un nouveau front qui n'existe dans aucun référentiel de contrôle de sécurité actualisé : la configuration de vos agents IA de code. Le 29 avril 2026, Mini Shai-Hulud a poussé la première campagne supply chain documentée à instrumentaliser .claude/settings.json et .vscode/tasks.json comme vecteurs d'implantation persistante. Ce n'est pas un détail technique mineur dans un rapport d'incident. C'est un changement de paradigme. Le poste développeur est devenu le nouveau périmètre critique — pas parce qu'il a des données sensibles (ce n'est pas nouveau), mais parce qu'il détient désormais un agent IA capable d'exécuter du code arbitraire, de déployer en production et d'accéder aux secrets cloud, le tout à partir d'un fichier JSON que personne dans votre organisation ne considère comme du code exécutable. Si votre politique de sécurité n'inclut pas encore les fichiers .claude/, .cursor/, et .vscode/tasks.json dans son périmètre d'audit et de gouvernance, vous avez un angle mort majeur que des attaquants ont déjà commencé à exploiter.

Ce qui vient de basculer : le poste développeur en 2026

Pendant quinze ans, le poste développeur était traité comme un endpoint sensible mais gérable. On y déployait un EDR, on bloquait les ports USB, on imposait le chiffrement disque, et on espérait que les pratiques d'hygiène feraient le reste. Les risques principaux identifiés étaient les malwares classiques, les fuites de credentials stockés en clair, et l'exécution accidentelle de code malicieux téléchargé depuis un dépôt compromis.

Le poste développeur de 2026 est une bête fondamentalement différente sur plusieurs dimensions.

Il manipule des secrets cloud à très haute valeur : root AWS, Owner Azure, kubeconfig prod avec accès au cluster Kubernetes de production. Ces secrets permettent souvent de déployer, modifier ou détruire l'intégralité de l'infrastructure cloud de l'organisation en quelques appels d'API. Leur compromission est équivalente à la compromission de l'intégralité du SI cloud.

Il commit dans des dépôts qui se déploient automatiquement en production via des pipelines CI/CD. Un développeur compromis qui pousse du code malicieux dans un dépôt avec déploiement automatique peut atteindre la production sans passer par aucun autre système. Le poste développeur est un accès direct à la production, pas un poste utilisateur standard.

Il fait tourner des agents IA qui exécutent du code à sa place, sur la base de prompts. Claude Code, Cursor, GitHub Copilot Workspace — ces outils peuvent lire des fichiers, exécuter des commandes shell, modifier du code, et déclencher des déploiements, le tout en réponse à des instructions textuelles. L'agent IA est un niveau d'abstraction entre le développeur et l'exécution — et c'est précisément cette couche d'abstraction que l'attaque Mini Shai-Hulud exploite.

L'attaque Mini Shai-Hulud : anatomie d'un vecteur inédit

Le 29 avril 2026, des chercheurs de Socket.dev et d'Aikido Security ont documenté une campagne supply chain ciblant des paquets npm liés à l'écosystème SAP CAP (Cloud Application Programming). L'attaque, baptisée Mini Shai-Hulud par les chercheurs en référence aux vers des sables de Dune, utilisait un mécanisme d'implantation particulièrement sophistiqué.

Les paquets malicieux publiés sur npm contenaient, parmi leurs fichiers de configuration commités, un fichier .claude/settings.json modifié. Ce fichier définissait un hook SessionStart — une fonctionnalité légitime de Claude Code qui permet d'exécuter des commandes au démarrage d'une session de l'agent IA — pointant vers un script malicieux hébergé à distance. La logique de l'attaque est élégante dans sa perversité : Claude Code ne demande pas de confirmation avant d'exécuter un hook SessionStart, et le hook est persistant tant que le projet est ouvert dans l'agent IA.

Le mécanisme équivalent existe dans VS Code via .vscode/tasks.json avec l'option runOn: "folderOpen". Un fichier de tâches VS Code qui déclare une tâche s'exécutant automatiquement à l'ouverture du dossier est un implant parfait : il s'active chaque fois qu'un développeur ouvre le projet, sans aucune interaction supplémentaire.

Ce qui rend ces vecteurs particulièrement insidieux : la persistance est portée par le dépôt Git, pas par la machine locale. Si un développeur nettoie complètement sa machine et clone à nouveau le dépôt, l'implant est de retour. La remédiation classique (scan de la machine, réinstallation de l'OS) est inefficace si le dépôt n'est pas également nettoyé. Et le dépôt peut avoir été commité par n'importe quel contributeur qui avait accès en écriture.

Pourquoi nos défenses actuelles sont aveugles sur ce vecteur

L'écart entre la surface d'attaque réelle et la couverture des outils défensifs est frappant.

Les pipelines CI/CD n'analysent pas les fichiers de configuration IDE. Snyk, Dependabot, OWASP Dependency-Check — ces outils analysent les dépendances (package.json, requirements.txt, pom.xml). Ils ne lisent pas .claude/settings.json. Ce fichier n'est pas dans leur modèle de risque, parce que le modèle de risque de ces outils a été conçu avant que les agents IA existent dans les environnements de développement.

La revue de code ignore les fichiers de configuration d'IDE. Dans la plupart des équipes, les règles informelles excluent les "dotfiles" de la revue de code stricte — "on ne commente pas les configurations d'éditeur des collègues". Un fichier .vscode/tasks.json qui ajoute une tâche malicieuse passera souvent sous le radar d'une revue de code concentrée sur la logique applicative. Et même si un reviewer regarde le fichier, il faut savoir que runOn: "folderOpen" est un mécanisme d'exécution automatique pour reconnaître la menace.

Les outils SAST ne cherchent pas les patterns de hooks IDE malicieux. Les outils d'analyse statique de code cherchent des injections SQL, des XSS, des secrets hardcodés, des algorithmes cryptographiques faibles. Ils ne cherchent pas des hooks SessionStart dans des fichiers JSON d'agent IA — parce que cette classe de vulnérabilité n'existe pas encore dans leurs bases de signatures.

Les EDR sont configurés pour surveiller les exécutions de processus, pas les actions des agents IA. Un agent IA qui exécute un script via un hook configuré dans un fichier JSON génère une exécution de processus qui, vue de l'EDR, ressemble à n'importe quelle autre exécution de terminal par le développeur. Sans règles de détection spécifiques sur les patterns d'exécution des agents IA, l'EDR ne voit rien d'anormal.

L'angle mort des hooks d'agent IA : une surface non gouvernée

Les hooks d'agent IA ont une légitimité opérationnelle réelle. SessionStart dans Claude Code permet de charger le contexte projet, vérifier des préconditions, lancer un linter. UserPromptSubmit peut imposer des règles de sécurité avant qu'une commande soit exécutée par l'agent. PreToolUse offre un point de contrôle avant tout appel d'outil (lecture de fichier, exécution de commande, appel d'API). Ces capacités sont utiles et légitimes.

Mais elles partagent une caractéristique critique : ce sont des mécanismes d'exécution de code arbitraire sans interaction de l'utilisateur au moment de l'exécution. Une fois le hook configuré, il s'exécute à chaque déclenchement du trigger — ouverture d'une session, soumission d'un prompt, appel d'un outil — sans aucune confirmation demandée.

Aucun standard ne définit aujourd'hui ce qu'est un hook d'agent IA légitime vs. malicieux. Aucun mécanisme natif ne permet de signer, d'attester ou de tracer les hooks de manière vérifiable. Claude Code n'affiche pas de confirmation au premier chargement d'un .claude/settings.json contenant des hooks — il les exécute. VS Code affiche une confirmation pour les tâches automatiques au premier démarrage, mais dans certaines configurations enterprise, cette confirmation est prévalidée par la politique d'équipe.

La documentation qui explique comment configurer ces hooks est publique, lisible en quelques minutes, et ne mentionne pas les implications de sécurité dans les configurations de base. La surface d'attaque est immense, documentée, et pratiquement non gouvernée dans la plupart des organisations.

Ce qu'il faut faire concrètement : la politique de sécurité IDE

Action 1 — Reclasser les fichiers de configuration IDE comme du code exécutable soumis à revue obligatoire. Les fichiers .claude/, .cursor/, .vscode/tasks.json, .github/workflows/, .devcontainer/, et tous les autres fichiers qui définissent des comportements automatiques dans l'environnement de développement doivent être traités avec la même rigueur qu'un script bash en CI. Cela signifie : ajout dans les règles CODEOWNERS pour imposer une revue d'une personne désignée, blocage des fusions sans approbation explicite, et formation des reviewers sur les patterns malicieux à identifier.

Action 2 — Audit récurrent du parc Git via les API GitHub/GitLab. Un script qui analyse tous les dépôts de l'organisation pour identifier les .claude/settings.json contenant des hooks SessionStart, les .vscode/tasks.json avec runOn:folderOpen, et les autres patterns de configuration automatique. Toute occurrence non documentée et approuvée explicitement doit déclencher une investigation. Ce script peut être exécuté quotidiennement via une action GitHub ou un pipeline CI dédié.

Action 3 — Politique d'organisation explicite sur les hooks d'agent IA. Une politique documentée et communiquée qui définit : quels hooks sont autorisés, qui peut les approuver, comment ils doivent être documentés dans le dépôt, et quelle est la procédure d'investigation quand un hook non documenté est découvert. Cette politique doit être intégrée dans les guidelines de développement de l'organisation, pas dans un document de sécurité que personne ne lit.

Action 4 — Isolation des credentials sur les postes développeurs. Les tokens GitHub, npm, AWS, les kubeconfig prod n'ont rien à faire en clair sur le disque du poste développeur. Un keystore système avec déverrouillage actif (Touch ID, Yubikey), des sessions courtes via OIDC fédéré, et l'usage de credentials_helper chiffrés réduisent drastiquement la valeur que représente un poste développeur compromis pour l'attaquant. Un hook malicieux qui exécute un script ne peut exfiltrer que ce qui est accessible — si les secrets ne sont pas sur le disque, la récolte est vide.

Action 5 — Règles de détection EDR sur les comportements des agents IA. Des règles qui alertent quand un processus associé à Claude Code, Cursor, VS Code ou GitHub Copilot exécute des commandes shell en dehors des patterns habituels (accès à des répertoires inhabituels, connexions réseau vers des destinations non répertoriées, création de fichiers dans des emplacements sensibles). Ces règles nécessitent une baseline de l'activité normale des agents IA sur les postes développeurs — un investissement initial, mais une couche de détection qui couvre exactement le vecteur documenté.

Conclusion

Le périmètre de sécurité n'est plus le réseau, ni le cloud, ni même le poste de travail au sens traditionnel. Le périmètre est l'IDE — parce que c'est lui qui détient désormais l'enchaînement complet : credentials cloud, accès Git avec droits de push, exécution de code arbitraire via agent IA, et déploiement direct en production. Une compromission de l'IDE via un fichier de configuration d'agent IA donne potentiellement accès à tout.

Toute organisation qui prend la cybersécurité au sérieux en 2026 doit traiter son IDE et ses agents IA de code comme des actifs critiques à gouverner, auditer, et protéger. Les fichiers de configuration .claude/, .cursor/, et .vscode/tasks.json sont du code exécutable. Traitez-les comme tel.