L’intégration rapide d’assistants d’intelligence artificielle au cœur des outils de développement ouvre de nouvelles perspectives de productivité. Elle introduit aussi des surfaces d’attaque inédites, encore largement sous-estimées. La récente vulnérabilité découverte dans Ask Gordon, l’assistant IA intégré à Docker Desktop, illustre les risques d’une automatisation trop confiante, où l’IA devient un intermédiaire direct entre des données externes et l’exécution de code.
Une faille révélatrice plus qu’un simple bug
Des chercheurs en cybersécurité ont mis au jour une vulnérabilité critique affectant Ask Gordon, l’assistant IA embarqué dans Docker Desktop et l’interface en ligne de commande de Docker. La faille permettait à un attaquant de dissimuler des instructions malveillantes dans les métadonnées d’images Docker, que l’assistant était ensuite capable d’interpréter comme des commandes légitimes.
Concrètement, certaines balises descriptives (LABEL) intégrées aux images pouvaient être lues par l’assistant lors de requêtes formulées par l’utilisateur. Ces données, pourtant non fiables par nature, étaient ensuite transmises à une couche d’exécution interne, ouvrant la voie à une exécution de code arbitraire ou à l’exfiltration de données sensibles. Docker a corrigé la vulnérabilité dans une mise à jour récente, mais l’incident dépasse largement le cadre d’un correctif ponctuel.
L’IA comme nouvel intermédiaire de confiance… parfois mal placée
Cette affaire met en lumière un changement de paradigme. Les assistants IA intégrés aux outils de développement ne se contentent plus de suggérer du code ou de répondre à des questions. Ils agissent comme des intermédiaires actifs, capables d’interpréter des informations externes et de déclencher des actions techniques avec les privilèges de l’utilisateur.
Or, dans le cas d’Ask Gordon, l’IA ne distinguait pas clairement une donnée descriptive d’une instruction potentiellement dangereuse. Ce glissement fonctionnel transforme l’assistant en vecteur indirect d’attaque, sans que l’utilisateur n’ait nécessairement conscience de ce qui est exécuté en arrière-plan.
Le problème n’est donc pas seulement technique. Il est aussi conceptuel. En intégrant des capacités d’exécution à des assistants conversationnels, les éditeurs déplacent la frontière entre aide à la décision et action automatisée, sans toujours adapter les garde-fous de sécurité en conséquence.
Une nouvelle forme de risque pour la supply chain logicielle
Au-delà de Docker, cette vulnérabilité soulève une question plus large de sécurité de la chaîne logicielle. Les images, extensions ou dépendances externes sont déjà des vecteurs de compromission bien connus. L’ajout d’une couche d’IA capable de lire, interpréter et exploiter ces contenus crée un effet amplificateur. Là où un développeur devait auparavant analyser manuellement un script ou une configuration, l’assistant IA peut désormais servir de relais involontaire, accélérant l’exploitation d’un contenu malveillant. Cette automatisation réduit les frictions, mais aussi les temps de détection et de réaction.
Pour les équipes de sécurité, le défi devient plus complexe. Il ne s’agit plus seulement de sécuriser le code ou les dépendances, mais aussi les comportements des assistants IA eux-mêmes, et les hypothèses de confiance qui leur sont associées.
Des garde-fous encore insuffisants
Docker a introduit des mécanismes de validation supplémentaires et des contrôles humains pour limiter l’exécution automatique d’instructions non vérifiées. Une réponse nécessaire, mais qui pose une question de fond. À mesure que les assistants IA se multiplient dans les environnements de développement, combien d’entre eux bénéficient réellement d’un modèle de sécurité robuste, pensé dès la conception ? Aujourd’hui, peu d’organisations disposent d’une visibilité claire sur les actions réalisées par ces assistants, leurs accès réels, ou les données qu’ils manipulent. Pourtant, ils opèrent souvent avec des droits étendus, au cœur même des environnements de production ou de préproduction.
L’IA embarquée, nouveau chantier pour les RSSI
Cet épisode agit comme un signal faible mais structurant. Les assistants IA ne peuvent plus être considérés comme de simples outils d’aide. Ils deviennent des composants à part entière du système d’information, avec leurs propres risques, privilèges et surfaces d’attaque. Pour les RSSI, cela implique d’élargir les modèles de menace existants et d’intégrer ces agents dans les politiques de contrôle d’accès, de journalisation et d’audit. À défaut, l’IA embarquée risque de devenir un angle mort de la sécurité, à la croisée du DevSecOps et de l’automatisation.
L’affaire Ask Gordon rappelle ainsi une évidence souvent oubliée. Plus l’IA est intégrée profondément dans les outils, plus elle doit être traitée comme une brique critique, et non comme une simple couche d’assistance.
