La sécurité des dépendances du code IA exige de traiter chaque package proposé par un agent comme non fiable tant qu’une politique et un examinateur humain ne l’ont pas approuvé. Les agents de codage IA peuvent choisir des dépendances, exécuter des gestionnaires de packages et accéder aux registres. Un package plausible mais inexistant peut donc devenir du code exécutable en quelques minutes. La sécurité des dépendances du code IA est la discipline qui contrôle la manière dont les dépendances générées par l’IA entrent, changent et quittent une compilation logicielle.
Pourquoi les agents de codage IA créent-ils un problème de dépendances ?
Les agents de codage IA créent un risque de dépendance parce qu’ils peuvent recommander des packages, modifier des manifestes, exécuter des commandes d’installation et accéder à des registres publics plus vite que les examinateurs ne peuvent valider chaque changement. VentureBeat a indiqué le 24 septembre 2026 que des assistants ajoutaient des packages, des bibliothèques et des images de conteneur alors que les cycles d’approbation en entreprise prenaient encore plusieurs jours.
La vitesse change la nature du problème. Un développeur peut ajouter quelques dépendances pendant un sprint de fonctionnalité, tandis qu’un agent autonome peut essayer à répétition des bibliothèques, abandonner des approches et laisser des packages indirects enfouis dans un lockfile. Chaque ajout élargit l’ensemble des responsables de maintenance, des systèmes de publication et des comptes de registre auxquels votre application accorde sa confiance.
Le risque ne se limite pas au code malveillant. Des bibliothèques abandonnées, des licences inattendues, des éditeurs compromis, des noms usurpés par typo-squatting et des versions incompatibles peuvent tous atteindre une compilation via une suggestion qui semble raisonnable dans une pull request. Les équipes déjà préoccupées par des dépôts malveillants qui détournent les agents de codage devraient appliquer le même scepticisme aux registres de packages.
L’examen traditionnel a aussi un problème de visibilité. Un ajout d’une seule ligne à package.json peut extraire des dizaines ou des centaines de composants transitifs, selon le package, la version et l’écosystème en 2026. Examiner le package direct sans inspecter l’arborescence résolue constitue donc une décision de sécurité incomplète.
Comment les packages hallucinés deviennent-ils des attaques de la chaîne d’approvisionnement ?
Les packages hallucinés deviennent des opportunités d’attaque lorsqu’un modèle d’IA suggère de façon répétée un nom plausible qui n’existe pas, permettant à un attaquant d’enregistrer ce nom et de publier du code hostile. Une étude universitaire de 2025 portant sur 16 modèles et 576,000 échantillons générés a mesuré un taux moyen d’hallucination de packages d’environ 19.6%.
L’étude, publiée via USENIX en 2025, montre pourquoi un échec d’installation n’est pas un bruit anodin. Des noms répétés fournissent à un attaquant un canal de distribution prêt à l’emploi : enregistrer le nom manquant, attendre que le code généré le demande, puis s’appuyer sur le comportement normal du gestionnaire de packages pour le récupérer.
Sonatype a signalé un problème de version connexe en 2026 après avoir analysé 36,870 recommandations de mise à niveau générées par des agents. Selon Sonatype, 27.76% faisaient référence à des versions inexistantes, dont plus de 10,000 versions publiées hallucinées. Le fait qu’un nom de package soit réel ne rend pas une version fabriquée sûre ; cela peut déclencher des compilations en échec, des substitutions non sûres ou une pression pour contourner les contrôles.
La propagation peut avoir lieu avant même que quiconque ne publie un logiciel malveillant. La Cloud Security Alliance a décrit le nom halluciné react-codeshift se propageant dans 237 dépôts dérivés avant qu’un chercheur ne l’enregistre à titre défensif en janvier 2026. Les forks peuvent conserver une mauvaise référence de dépendance longtemps après la disparition de la sortie d’origine.
L’aide-mémoire OWASP Secure Coding with AI, consulté le 1 octobre 2026, recommande de vérifier chaque package suggéré dans son registre réel et d’examiner sa date de création, son activité de téléchargement et l’historique de son responsable de maintenance. OWASP considère les packages de moins de 30 jours avec une suspicion particulière. À mon avis, un échec d’installation devrait être consigné comme un signal de sécurité, et non écarté comme si l’agent faisait simplement une autre faute de frappe.
Que devrait exiger une politique d’approbation des dépendances IA ?
Une politique d’approbation des dépendances d’IA devrait exiger que l’agent identifie l’objectif de la dépendance, le package exact et sa version, le registre, l’état de maintenance et les alternatives rejetées avant l’installation. La sécurité des dépendances de codage par IA doit ensuite faire appliquer la décision en dehors du modèle au moyen de règles d’intégration continue, de registres approuvés et d’une autorisation humaine pour les changements sensibles.
L’explication d’un modèle constitue une preuve, pas un mécanisme d’application. Les instructions du prompt peuvent être ignorées, mal comprises ou évincées par un contenu de dépôt hostile. Le modèle le plus sûr est simple : l’agent peut proposer une dépendance, mais un contrôle distinct décide si ce package peut entrer dans la build.
La liste de contrôle suivante couvre le parcours minimal de révision pour chaque dépendance nouvelle ou modifiée :
- Confirmez que le package exact et sa version existent dans le registre prévu, et rejetez les substitutions silencieuses.
- Consignez l’objectif du package, son éditeur, sa date de création, l’activité des versions, la licence et l’historique de maintenance.
- Comparez au moins une alternative sans dépendance ou déjà approuvée, y compris le coût d’écriture locale de la fonction requise.
- Limitez les téléchargements aux registres internes ou publics approuvés au moyen de listes d’autorisation réseau et de la politique du dépôt.
- Exigez des modifications révisées du manifeste et du fichier de verrouillage, des valeurs d’intégrité, un diff des dépendances et une nomenclature logicielle.
- Analysez les dépendances directes et transitives avant la fusion, puis faites échouer l’intégration continue au seuil de gravité défini par l’organisation.
- Envoyez l’installation, les exceptions à la politique du registre et les exceptions à fort impact vers une étape d’approbation humaine que l’agent ne peut pas approuver lui-même.
Cette approche empêche aussi la prolifération des dépendances. Si un package économise 20 lignes de code mais introduit 40 composants transitifs, la révision devrait mesurer la confiance supplémentaire requise au lieu d’admirer le fichier source plus court. Honnêtement, une petite fonction locale a souvent plus de sens lorsque l’alternative crée un grand arbre de dépendances faiblement maintenu.
La publication spéciale 800-204D du NIST a recommandé des listes d’autorisation de sources fiables, la vérification des signatures, l’analyse des vulnérabilités, les contrôles de mise à jour et les nomenclatures logicielles en 2024. Le NIST a également recommandé de commencer l’analyse des dépendances dès le premier commit, plutôt que de la reporter jusqu’à la mise en production. Ces contrôles s’intègrent naturellement à côté d’une évaluation plus large de la chaîne d’approvisionnement des tiers.
Comment l’intégration continue doit-elle vérifier les modifications de dépendances générées par l’IA ?
L’intégration continue devrait rejeter les modifications de dépendances générées par l’IA à moins que le manifeste, le fichier de verrouillage révisé, les données d’intégrité, le diff des dépendances, les résultats de vulnérabilité et la nomenclature logicielle ne concordent. Pour les projets npm en 2026, l’installation déterministe et les fichiers package-lock.json validés donnent aux réviseurs un arbre de dépendances défini au lieu d’une plage de versions mouvante.
Selon la documentation npm consultée le 1 octobre 2026, package-lock.json enregistre les artefacts résolus ainsi que les valeurs d’intégrité SHA-512 ou SHA-1. La norme npm audit le flux de travail nécessite normalement un fichier de verrouillage, car un audit a besoin d’un arbre défini. Une pull request contenant uniquement un manifeste devrait échouer automatiquement.
| Contrôle | Preuve examinée | Condition d’échec |
|---|---|---|
| Vérification du registre | Package, version, éditeur et registre approuvé exacts | Le nom ou la version est manquant, substitué ou récupéré depuis une source non approuvée |
| Installation déterministe | Validé package-lock.json et artefacts résolus |
Modifications du manifeste sans modifications correspondantes et examinées du fichier de verrouillage |
| Intégrité et provenance | Hachages d’intégrité, signatures du registre et attestations disponibles | L’artefact diffère des données verrouillées ou la vérification requise échoue |
| Analyse des vulnérabilités | Résultats concernant les dépendances directes et transitives | Un résultat atteint le seuil de rejet documenté de l’organisation |
| Comparaison de la SBOM | Inventaire SPDX ou CycloneDX par rapport à la build approuvée précédente | Un composant, une version, une source ou une dépendance transitive inattendu apparaît |
la documentation npm consultée en 2026 indique que les signatures d’audit npm vérifient les signatures du registre et les attestations de provenance. La vérification de provenance nécessite npm CLI 9.5.0 ou une version ultérieure. Les signatures ne prouvent pas qu’un package est inoffensif, mais elles peuvent établir si l’artefact et les preuves concernant l’éditeur correspondent à ce que présente le registre.
Générez une nomenclature logicielle pour chaque build, et pas seulement pour une version majeure. npm peut produire des sorties SPDX ou CycloneDX, tandis que le NIST et la Cybersecurity and Infrastructure Security Agency décrivent les SBOM comme des inventaires logiciels lisibles par machine. La comparaison d’inventaires successifs révèle le coût caché d’une minuscule modification du manifeste.
L’analyse seule est trop limitée. Une base de données de vulnérabilités peut ne contenir aucune entrée pour un package malveillant nouvellement créé, donc la sécurité des dépendances du codage par IA doit aussi évaluer l’âge du package, le registre, l’éditeur et la provenance. Un raisonnement similaire s’applique lorsque les équipes utilisent des agents IA pendant la revue de code: les résultats automatisés éclairent le jugement au lieu de le remplacer.
Quelles autorisations faut-il accorder aux agents de codage ?
Les agents de codage doivent recevoir des identités distinctes, des identifiants à courte durée de vie et uniquement les autorisations d’interpréteur de commandes, de système de fichiers, de gestionnaire de paquets et de réseau nécessaires pour le dépôt assigné. Les recommandations 2026 de GitHub préconisent des outils restreints et une approbation humaine pour les opérations sensibles, tandis que les commits rédigés par les agents et les journaux de session préservent l’attribution après un incident.
L’accès au registre doit être explicite. Le pare-feu de l’agent cloud de GitHub prend en charge les règles de domaine ou d’URL au niveau de l’organisation et du dépôt, selon la documentation consultée le 1er octobre 2026, bien que GitHub avertisse que le pare-feu n’est pas exhaustif. Le filtrage réseau doit compléter la politique relative aux paquets, et non s’y substituer.
L’écart d’identité reste considérable. VentureBeat Pulse a rapporté le 12 août 2026 que 65% des entreprises interrogées imposaient des autorisations d’agent délimitées, mais que seules 18% isolaient leurs agents les plus à risque et que 53% avaient connu un incident de sécurité lié à un agent ou un quasi-incident. Un autre rapport de VentureBeat a situé à seulement 8% la part combinant application à l’exécution et isolement des agents à haut risque en 2026.
Voici le calcul souvent négligé : 65% d’application moins 8% combinant application et isolement laisse un écart de 57 points de pourcentage entre le contrôle de base des autorisations et le contrôle renforcé associé dans cette enquête de 2026. Les autorisations aident, mais une infrastructure et des identifiants partagés peuvent encore transformer la compromission d’un seul agent en incident plus large.
Les identifiants partagés affaiblissent aussi l’attribution. Le 30 septembre 2026, VentureBeat a rapporté que 22 des 37 organisations interrogées exploitant des agents de production avec des autorisations appliquées permettaient encore à certains ou à la plupart des agents de partager des identifiants. Un journal affichant « compte d’automatisation » ne suffit pas lorsque plusieurs agents peuvent utiliser le même secret.
Gardez l’approbation hors de portée de l’agent. Une démonstration d’injection d’invite du 26 août 2026 rapportée par VentureBeat a montré un agent utilisant des identifiants existants pour effectuer une modification DNS non autorisée. Le modèle recommandé permet à un agent de proposer une action à fort impact tout en l’empêchant d’approuver cette action, un modèle utile pour l’installation de packages et les exceptions de registre ainsi que pour les modifications d’infrastructure. Les équipes doivent aussi tenir compte des façons plus générales dont les agents de codage choisissent et invoquent des outils.
Questions fréquemment posées
Un lockfile peut-il arrêter un package npm malveillant ?
Un lockfile ne peut pas déterminer si un package npm est malveillant. Un package-lock.json corrige l’arborescence résolue et enregistre les données d’intégrité en 2026, aidant l’intégration continue à détecter des artefacts inattendus ou des changements de dépendances.
npm audit est-il suffisant pour la sécurité des dépendances du codage IA ?
npm audit n’est pas suffisant pour la sécurité des dépendances du codage IA, car l’analyse des vulnérabilités peut passer à côté de paquets nouveaux, hallucinés ou délibérément malveillants. L’identité du registre, l’ancienneté du paquet, l’historique de l’éditeur, les signatures, la provenance et les différences de SBOM nécessitent des vérifications distinctes en 2026.
Les agents de codage doivent-ils être autorisés à installer des paquets ?
Les agents de codage peuvent installer des paquets dans un environnement isolé lorsque des listes d’autorisation du registre, des identifiants à portée limitée, des builds déterministes et des étapes d’approbation externes encadrent cette action. Les builds de production doivent rejeter les modifications non examinées du manifeste ou du lockfile en 2026.
Que doit expliquer un agent avant d’ajouter une dépendance ?
Un agent de codage IA doit indiquer l’objectif de la dépendance, le paquet exact et sa version, le registre source, l’état de maintenance et les alternatives rejetées. La politique d’intégration continue et un relecteur humain doivent vérifier cette explication avant que la dépendance n’entre dans un build de 2026.