Pendant que les RSSI restent obsédés par le périmètre cloud et les EDR sur poste, les attaquants ont déjà ouvert un nouveau front : la configuration de vos agents IA de code. Le 29 avril 2026, Mini Shai-Hulud a poussé la première campagne supply chain à instrumentaliser .claude/settings.json et .vscode/tasks.json comme implants. Ce n'est pas un détail technique. C'est un changement de paradigme.

Ce qui vient de basculer

Pendant quinze ans, le poste développeur était un endpoint comme un autre. On y déployait l'antivirus de l'entreprise, on y bloquait les ports USB et on espérait que les pratiques d'hygiène feraient le reste. Le poste développeur d'aujourd'hui est une bête différente : il manipule des secrets cloud à très haute valeur (root AWS, Owner Azure, kubeconfig prod), il commit dans des dépôts qui se déploient automatiquement en production, et il fait tourner des agents IA qui exécutent du code à sa place sur la base de prompts.

L'attaque Mini Shai-Hulud sur les paquets SAP CAP du 29 avril a démontré que l'attaquant n'a plus besoin d'exécuter une charge sur le poste : il lui suffit d'injecter un .claude/settings.json dans un dépôt GitHub, et la charge se rejoue chaque fois qu'un développeur ouvre le projet dans Claude Code via le hook SessionStart. Idem pour le .vscode/tasks.json avec runOn=folderOpen. La persistance est portée par le dépôt, pas par la machine. Nettoyer le poste ne suffit plus.

Pourquoi nos défenses actuelles passent à côté

Le pipeline CI/CD analyse les dépendances avec Snyk, Dependabot ou Trivy. Il ne lit pas vos fichiers .claude/. La revue de code regarde le code applicatif, pas les fichiers de configuration d'IDE — qui sont souvent même exclus du scope de revue par les règles d'équipe "on ne touche pas aux dotfiles des autres". Le SAST cherche des patterns d'injection SQL ou de XSS, pas des hooks shell dans des fichiers JSON.

Pire : la plupart des organisations encouragent activement le partage des configurations d'éditeur via le dépôt, au nom de la cohérence d'équipe. Le .vscode/settings.json est commité parce qu'il configure l'indentation, le linter et le formateur. On a normalisé l'idée que la configuration d'IDE traverse Git. L'attaquant n'a fait que tirer la conséquence logique de cette norme.

L'angle mort des hooks d'agent IA

Les hooks Claude Code et leurs équivalents Cursor/Copilot ont une légitimité opérationnelle. SessionStart permet de charger un contexte projet, de vérifier des préconditions, de lancer un linter. UserPromptSubmit peut imposer des règles avant qu'une commande ne soit exécutée. PreToolUse offre un point de contrôle avant tout appel d'outil. Toutes ces capacités sont utiles. Toutes sont, par construction, du code arbitraire qui s'exécute sans interaction de l'utilisateur dès l'ouverture d'un projet.

Aucun standard ne définit aujourd'hui ce qu'est un hook IA légitime. Aucun mécanisme natif ne permet de signer ou d'attester un hook. L'utilisateur n'a pas de prompt de confirmation au premier chargement. La surface d'attaque est immense, et la documentation qui explique comment exploiter ces hooks est publique, lisible en cinq minutes.

Ce qu'il faut faire, sans attendre

D'abord : reclasser les fichiers .claude/, .cursor/, .vscode/, .github/ et .devcontainer/ comme du code exécutable. Ils doivent passer en revue de code obligatoire avec la même rigueur qu'un script bash en CI. Les CODEOWNERS doivent inclure ces chemins, et la fusion sans approbation explicite doit être bloquée.

Ensuite : audit récurrent du parc Git via les API GitHub/GitLab pour énumérer tous les .claude/settings.json contenant un hook SessionStart, et tous les .vscode/tasks.json avec runOn=folderOpen. Toute occurrence non documentée par l'équipe doit déclencher une investigation, pas une discussion.

Ensuite : politique d'organisation explicite. Les hooks d'agent IA et les tâches automatiques d'IDE doivent être autorisés via une allowlist signée et centralisée, jamais via des fichiers commités librement. Les outils d'enterprise pour Claude Code et VS Code permettent déjà de pousser ces politiques via MDM.

Enfin : isolation des credentials. Les jetons GitHub, npm, AWS et kubeconfig n'ont rien à faire sur la machine de développement en clair. Un keystore système avec déverrouillage actif (Touch ID, Yubikey), des sessions courtes via OIDC fédéré, et l'usage systématique de credentials_helper signés et chiffrés réduisent drastiquement la valeur d'un poste compromis pour l'attaquant.

Mon avis d'expert

L'industrie a passé deux ans à se féliciter d'avoir adopté les agents IA de code sans avoir la moindre conversation sérieuse sur leur modèle de menace. On a poussé Claude Code, Cursor et Copilot dans toutes les équipes au nom de la productivité, sans charger les RSSI d'écrire la politique correspondante. Mini Shai-Hulud n'est que le premier rappel à l'ordre. Il y en aura d'autres, et ils seront plus créatifs. Si vous attendez l'incident pour réagir, vous serez en retard d'au moins deux trimestres sur l'attaquant.

Conclusion

Le périmètre n'est plus le réseau, ni le cloud, ni même le poste. Le périmètre est l'IDE, parce que c'est lui qui détient l'enchaînement complet : credentials cloud, accès Git, exécution de code arbitraire via agent IA, et déploiement direct en production. Toute organisation qui prend la cybersécurité au sérieux en 2026 doit traiter son IDE comme un actif critique, avec inventaire, politique, audit et formation. Le reste n'est qu'une façade.

Prêt à structurer une politique de sécurité IDE pour votre organisation ?

Définition de politique, audit du parc, hardening Claude Code et VS Code, plan de détection : Ayi NEDJIMI accompagne vos équipes DevSecOps de bout en bout.

Prendre contact