Et si le prochain problème de sécurité de votre entreprise ne venait pas d’un serveur mal configuré, mais d’une recommandation faite par votre assistant IA ?
C’est le scénario particulièrement révélateur décrit par Mandiant dans son rapport AI Risk and Resilience 2026. Un attaquant a détourné une session active d’un assistant de programmation IA chez un fournisseur SaaS. Il a ensuite utilisé cette session pour faire installer un paquet PyPI compromis, récupérer des tokens OAuth GitHub et propager le ver Shai-Hulud dans environ 100 dépôts de code internes. :contentReference[oaicite:0]{index=0}
L’IA n’a pas simplement été confrontée à une attaque classique.
Elle faisait partie de la chaîne de confiance utilisée par l’attaquant.
Le développeur pensait simplement installer un outil
Dans le scénario analysé par Mandiant, l’attaquant a réussi à prendre le contrôle d’une session active d’un assistant de programmation utilisant les privilèges de l’environnement du développeur.
L’assistant a ensuite recommandé un paquet logiciel tiers. Le développeur a accepté la recommandation.
Le problème était précisément là : le paquet avait été empoisonné.
Son installation a permis de déployer un infostealer capable de récupérer des informations sensibles présentes dans l’environnement. :contentReference[oaicite:1]{index=1}
Pendant longtemps, l’attaquant devait convaincre directement le développeur d’exécuter quelque chose.
Ici, il cherche plutôt à faire en sorte que l’environnement de développement fasse lui-même confiance à l’action.
Une dépendance peut devenir une porte d’entrée
Le développement moderne repose énormément sur les dépendances. Un projet peut utiliser des dizaines, des centaines, voire des milliers de composants provenant de registres publics.
Cette mécanique apporte une puissance considérable aux développeurs. Mais elle crée également une chaîne de confiance complexe.
Lorsqu’un assistant IA commence à participer aux décisions techniques, une nouvelle question apparaît :
Non.
Une IA peut proposer le paquet qui semble répondre au problème posé sans constituer pour autant une autorité de confiance sur sa provenance, son intégrité ou son historique.
SOUS LE CAPOT : comment la chaîne s’enchaîne
L’intérêt de cette attaque réside dans la succession des étapes. Aucune d’elles ne semble nécessairement spectaculaire prise isolément. C’est leur combinaison qui devient dangereuse.
Une session active d’assistant de programmation est compromise.
↓
02 — RECOMMANDATION
Un paquet logiciel compromis est recommandé.
↓
03 — INSTALLATION
Le développeur accepte la recommandation.
↓
04 — VOL DE SECRETS
L’infostealer récupère des informations sensibles.
↓
05 — TOKENS GITHUB
Les credentials permettent d’étendre le périmètre de l’attaque.
↓
06 — PROPAGATION
Shai-Hulud se propage dans environ 100 dépôts internes.
Le moment où le poste du développeur ne suffit plus
Tant que l’incident reste limité au poste compromis, le problème est déjà sérieux. Mais le vol de credentials change complètement la situation.
Selon Mandiant, l’attaque a permis de récupérer des tokens OAuth GitHub. L’attaquant pouvait alors utiliser l’identité et les permissions associées à cet environnement pour aller plus loin. :contentReference[oaicite:2]{index=2}
Ce n’est pas simplement une chaîne de caractères.
Il peut représenter des permissions, un accès à des ressources et une capacité d’action.
Voler les credentials d’un développeur peut donc transformer une compromission locale en problème d’infrastructure.
Shai-Hulud transforme ensuite l’accès en propagation
Une fois les accès obtenus, le ver Shai-Hulud a été utilisé pour se propager dans environ 100 dépôts internes.
Mandiant indique que le ver automatisait notamment la recherche et le vol de secrets présents dans les dépôts ainsi que l’exfiltration de code source propriétaire. :contentReference[oaicite:3]{index=3}
L’organisation compromise a ensuite vu un paquet appartenant à son propre espace de noms officiel être empoisonné. Une nouvelle infection a pu se produire lorsqu’un autre employé a récupéré cette version compromise.
L’attaquant n’a pas nécessairement besoin de convaincre chaque développeur.
Il cherche à compromettre suffisamment profondément la chaîne de confiance pour que le système propage lui-même le problème.
Le problème n’est donc pas simplement « l’IA »
Il serait facile de résumer cette affaire par : « Les assistants IA sont dangereux. »
Ce serait pourtant manquer le cœur du problème.
L’assistant IA évolue désormais dans un environnement qui contient déjà des fichiers source, des dépôts Git, des variables d’environnement, des clés API, des tokens et parfois des accès cloud.
Plus l’agent devient capable d’agir directement, plus la question des permissions devient centrale.
peuvent former une surface d’attaque beaucoup plus large qu’un simple chatbot isolé.
Le signal envoyé par Mandiant
L’étude ne s’arrête pas au cas particulier de Shai-Hulud. Mandiant décrit plus largement une évolution des menaces autour des assistants et agents de programmation.
À mesure que ces systèmes obtiennent davantage d’accès aux outils, aux données et aux environnements de développement, les frontières traditionnelles entre identité, application et automatisation deviennent moins nettes.
C’est précisément cette évolution que les entreprises doivent commencer à intégrer dans leur modèle de sécurité.
La question n’est plus seulement : « Cette IA est-elle sûre ? »
Il faut également demander : « Que peut-elle voir, télécharger, exécuter et modifier ? »
Pourquoi les assistants de programmation sont une nouvelle surface d’attaque
Un assistant de programmation moderne n’est plus forcément une simple fenêtre dans laquelle un développeur pose une question.
Selon son intégration, il peut interagir avec le dépôt, analyser des fichiers, utiliser des outils, lancer des commandes ou accéder à différents composants de l’environnement de développement.
Cette puissance est précisément ce qui rend ces outils intéressants. Mais elle augmente aussi le coût d’une compromission.
L’automatisation ne doit jamais devenir une permission implicite.
Les protections recommandées
Mandiant recommande notamment de renforcer les contrôles autour des dépendances recommandées par les assistants IA.
Les logiciels recommandés par l’IA doivent pouvoir être comparés à des signatures, empreintes cryptographiques ou listes de dépendances autorisées.
02 — Isoler les credentials
Les clés API, tokens OAuth longue durée et autres secrets ne devraient pas être accessibles sans contrôle aux extensions et assistants.
03 — Contrôler les téléchargements
Les dépendances doivent idéalement passer par des dépôts internes ou des mécanismes permettant d’en contrôler l’intégrité et la provenance.
Ces mesures figurent parmi les contrôles défensifs proposés par Mandiant pour sécuriser le développement assisté par IA. :contentReference[oaicite:4]{index=4}
Et si le véritable problème était la confiance ?
Il y a quelque chose de nouveau dans cette histoire.
Un développeur peut naturellement se méfier d’une commande copiée depuis un forum inconnu.
Mais une recommandation formulée par son propre assistant de programmation bénéficie d’un niveau de confiance différent.
↓
« Il doit donc probablement répondre à mon besoin. »
↓
« Je peux l’installer. »
↓
Et la chaîne d’attaque commence.
Analyse HexaOS : l’IA devient une nouvelle identité technique
C’est ici que cette affaire devient particulièrement intéressante.
Pendant des années, la sécurité informatique a raisonné autour des utilisateurs humains, des serveurs et des applications.
Les agents IA ajoutent progressivement une nouvelle catégorie : des logiciels capables d’agir avec une identité et des permissions.
Cette évolution impose une nouvelle question :
Probablement pas.
Ce que les entreprises doivent commencer à contrôler
- Les dépôts auxquels les assistants peuvent accéder.
- Les commandes qu’ils peuvent exécuter.
- Les extensions capables de lire des secrets.
- Les tokens présents sur les postes de développement.
- Les paquets pouvant être installés automatiquement.
- Les flux réseau utilisés pour récupérer les dépendances.
- Les journaux permettant de reconstruire les actions d’un agent.
Verdict HexaOS
Shai-Hulud raconte quelque chose de beaucoup plus important qu’une nouvelle histoire de malware.
L’assistant IA devient progressivement une interface entre le développeur et son environnement technique.
Et dès qu’une interface possède une identité, des permissions et un accès au code, elle devient également intéressante pour un attaquant.
Le véritable enjeu n’est donc pas de savoir s’il faut arrêter d’utiliser l’IA pour programmer.
Il faut décider exactement jusqu’où nous sommes prêts à lui faire confiance.
Parce que demain, le problème ne sera peut-être plus :
« Qui a accès au dépôt ? »
Mais :
« Qui a appris à l’IA à y accéder ? »
Sources
Article HexaOS — cybersécurité, IA et sécurité de la chaîne logicielle. Les informations techniques relatives à l’incident sont fondées notamment sur l’étude de Mandiant et les publications du CERT-FR.
