Un agent de codage peut résoudre une erreur en installant une bibliothèque, en modifiant un fichier de verrouillage (lockfile), en mettant à jour une image de base ou en lançant une commande dans le terminal. La fonctionnalité fonctionne à nouveau, les tests passent et l’équipe avance. Mais chaque paquet ajouté entre dans la chaîne d’approvisionnement (supply chain) du produit : code tiers, dépendances transitives, scripts d’installation, licences, vulnérabilités et comportement dans le pipeline.

Le risque ne concerne pas seulement les paquets vulnérables. Il naît lorsque l’agent choisit des composants et des commandes pour faire fonctionner rapidement une fonctionnalité sans évaluer la maturité, la maintenance, la licence, le typosquatting, le lockfile, le conteneur, le registre, les jetons (tokens), la SBOM et les contrôles de fusion (merge).

Pour les ingénieurs DevOps, les ingénieurs sécurité et les CTO, la question concrète avant la fusion est : quelles nouvelles dépendances l’IA a-t-elle introduites, pourquoi sont-elles nécessaires, que font-elles, quels composants transitifs apportent-elles, quels scripts lancent-elles, quelles licences possèdent-elles et comment seront-elles surveillées après le déploiement ?

[Callforaction-WAPT]

Quand l’IA installe un paquet pour résoudre une erreur

Le schéma est courant : la build échoue, un analyseur manque, un SDK n’est pas configuré, un test nécessite un mock ou un composant frontend a besoin d’un utilitaire. L’assistant suggère npm install, pip install, cargo add ou go get, met à jour package.json, modifie requirements.txt, change un lockfile ou insère une dépendance dans le Dockerfile.

Ce raccourci peut être correct, mais il doit être révisé comme une modification de sécurité. Une bibliothèque n’est pas seulement une fonction supplémentaire : elle peut exécuter du code lors de l’installation, importer des dizaines de paquets transitifs, avoir une licence incompatible, être peu maintenue ou introduire des vulnérabilités connues. La première question n’est pas “le paquet fonctionne-t-il ?”, mais “est-il vraiment nécessaire ?”. Si le projet possède déjà une bibliothèque équivalente, si le problème se résout avec quelques lignes de code clair ou si la dépendance n’est ajoutée que pour faire passer un test, le coût en termes de supply chain peut dépasser le bénéfice.

Prolifération des dépendances (Dependency sprawl) : le coût caché du “vibe coding”

La prolifération des dépendances signifie accumuler des bibliothèques parce que chacune résout un petit problème local. Avec les agents de codage IA, ce phénomène s’accélère, car l’agent ne ressent pas le poids opérationnel de la maintenance des paquets dans le temps : il installe, adapte le code et passe à autre chose.

Le coût arrive plus tard : mises à jour de sécurité, incompatibilités entre versions, bundle plus volumineux, builds plus lentes, licences à gérer, CVE à trier, dépendances transitives à surveiller, conteneurs plus lourds, SBOM plus complexe et surface d’attaque plus large. Une règle pratique aide : chaque nouvelle dépendance doit avoir une motivation, un propriétaire et une alternative évaluée. Si personne ne sait pourquoi elle a été ajoutée ou quel risque elle introduit, elle ne devrait pas être fusionnée simplement parce que l’IA l’a suggéré.

Typosquatting et paquets quasi homonymes

Les modèles peuvent suggérer des noms plausibles qui correspondent parfois au bon paquet, et d’autres fois à une alternative peu connue, un wrapper non maintenu ou un paquet créé pour intercepter les erreurs de frappe. Le risque augmente lorsque l’agent installe automatiquement sans faire passer le choix par un contrôle humain.

Avant d’accepter un paquet, il est nécessaire de vérifier le registre, le dépôt officiel, les mainteneurs, les versions récentes, les issues ouvertes, le volume de téléchargements, la signature ou la provenance si disponible, la documentation et la communauté. Il ne suffit pas que le nom semble familier : dans des écosystèmes comme npm et PyPI, des différences minimes dans le nom peuvent mener à des paquets complètement différents. Pour les paquets critiques, il vaut la peine d’évaluer également la chaîne des mainteneurs, car un projet légitime mais abandonné, acquis ou avec des versions soudaines après des années de silence nécessite de la prudence, tant sur le plan technique que sur celui de la confiance dans la maintenance.

Dépendances transitives et lockfiles

Le manifeste montre ce que l’équipe a déclaré vouloir utiliser ; le lockfile montre ce qui entrera réellement dans la build. Une seule dépendance peut apporter des dizaines ou des centaines de paquets transitifs, et une mise à jour automatique peut changer des versions non prévues. Un lockfile régénéré peut cacher une surface beaucoup plus large que le diff visible dans package.json.

Le lockfile doit être révisé avec le manifeste. Si l’IA met à jour package-lock.json, pnpm-lock.yaml, yarn.lock, poetry.lock, uv.lock, Pipfile.lock, go.sum ou Cargo.lock, le relecteur doit comprendre ce qui a changé : nouveaux paquets, mises à jour majeures, scripts, sources de registre et arbre de dépendances. Il n’est pas nécessaire de lire chaque ligne manuellement, mais il faut avoir une visibilité sur ce qui a été ajouté. Pour réduire le bruit, il convient de séparer les mises à jour intentionnelles des fonctionnalités : une PR qui ajoute une fonctionnalité et met à jour la moitié du lockfile est difficile à valider ; il est donc préférable d’isoler la dépendance nécessaire, de verrouiller les versions et d’éviter latest.

Scripts d’installation et hooks de cycle de vie

De nombreux gestionnaires de paquets autorisent des scripts en phase d’installation ou de build : preinstall, install, postinstall, prepare, scripts de configuration, scripts de build, plugins et hooks. Ces scripts peuvent exécuter du code sur les ordinateurs des développeurs, en CI/CD ou dans des conteneurs. Si l’IA ajoute un paquet sans vérifier ces scripts, elle autorise de fait du code tiers à s’exécuter dans le processus de build.

La revue doit rechercher des scripts nouveaux ou modifiés dans les manifestes et les paquets ajoutés. Une commande apparemment innocente peut télécharger des binaires, générer du code, lire des variables d’environnement, envoyer des télémétries ou altérer des fichiers. Dans les environnements CI avec des jetons et des secrets, un script d’installation malveillant peut avoir un impact sérieux. Lorsque cela est possible, il est utile d’adopter des politiques qui limitent l’exécution de scripts, des builds en sandbox, des jetons avec un périmètre minimal et des registres contrôlés.

Licences et conformité du code tiers

La supply chain ne concerne pas seulement les vulnérabilités. Une bibliothèque peut être techniquement sûre et commercialement problématique : licences copyleft, restrictions d’utilisation, obligations d’attribution, incompatibilités avec la distribution propriétaire ou avec les politiques client peuvent rendre une dépendance inadaptée au contexte.

Les agents IA ne prennent pas toujours en compte les contraintes de licence. Si vous demandez d’ajouter une bibliothèque pour exporter des PDF, l’assistant peut choisir ce qu’il connaît ou ce qui fonctionne, pas nécessairement ce qui est compatible avec le modèle économique ou le contrat client. Pour les éditeurs de logiciels et les produits B2B, chaque nouvelle dépendance devrait passer par une analyse de licence ou une liste blanche (allowlist). Les exceptions doivent être documentées, car en l’absence de politique, le risque émerge tardivement : lors d’une due diligence, d’un audit client, d’un approvisionnement en entreprise ou de la préparation à la mise en production.

Conteneurs, images de base et paquets système

Le risque de supply chain ne s’arrête pas au code applicatif. Un agent peut modifier des Dockerfiles, des images de base, des paquets OS, des installateurs, des scripts curl, des dépôts apt, des versions Node ou Python, des étapes de build et des permissions d’exécution. Il peut utiliser latest, installer des outils inutiles ou laisser l’application s’exécuter en tant que root.

Chaque image doit être traitée comme un composant du produit. Les pratiques recommandées incluent des images de base minimales et maintenues, le verrouillage des versions (pinning), l’analyse des conteneurs, l’utilisation d’un utilisateur non-root lorsque c’est possible, la réduction des paquets OS, des builds multi-étapes propres et l’absence de secrets dans les couches. Si l’IA ajoute un modèle du type curl | sh, il est nécessaire de s’arrêter et de vérifier la source, la signature, la somme de contrôle et la nécessité avant de procéder. Une build qui passe parce que le conteneur installe “tout ce qu’il faut” peut devenir difficile à patcher et à surveiller dans le temps.

Écosystèmes différents, signaux différents

Le contrôle de la supply chain change en fonction de la pile technologique. Dans Node.js, le risque passe souvent par package.json, le lockfile, les scripts npm, les paquets transitifs et le bundle frontend. En Python, il faut regarder requirements.txt, pyproject.toml, le lockfile, les wheels, les dépendances natives, les index privés et les paquets quasi homonymes. En Go, go.mod et go.sum rendent le graphe de dépendances plus clair, mais il faut tout de même vérifier les chemins de module, les directives de remplacement et les sources. En Rust, Cargo.toml et Cargo.lock montrent les crates et les fonctionnalités activées.

Un agent IA peut connaître la syntaxe de tous ces écosystèmes, mais il ne connaît pas les politiques de l’équipe. Il peut utiliser npm audit fix en changeant plus de versions que nécessaire, installer un paquet Python non approuvé, ajouter une fonctionnalité Cargo qui apporte du code non prévu ou modifier un Dockerfile pour installer des bibliothèques système sans verrouillage de version. Pour chaque écosystème, la règle est la même : le manifeste et le lockfile doivent être lus ensemble, les sources des paquets doivent être connues et les mises à jour automatiques doivent être séparées des fonctionnalités. Si le projet utilise des registres privés, il est important de vérifier également les replis (fallbacks) et les priorités, car une mauvaise configuration peut télécharger un paquet public au lieu du paquet interne.

Confusion de dépendances (Dependency confusion) et registres privés

Les entreprises qui utilisent des paquets internes doivent considérer le risque de confusion de dépendances. Si un paquet privé a un nom qui peut également exister sur un registre public, une mauvaise configuration du gestionnaire de paquets peut télécharger le mauvais composant. Les agents IA peuvent aggraver le problème en générant des configurations de registre génériques ou en supprimant des paramètres parce qu’ils “ne sont pas nécessaires” à la build locale.

Il est nécessaire de contrôler les scopes npm, les index Python, les registres Docker, GitHub Packages, GitLab Package Registry, les proxys d’entreprise et les miroirs, en vérifiant que les paquets internes sont résolus par le registre correct, que les jetons ont un périmètre minimal et que les logs n’exposent pas d’identifiants. Si un agent modifie .npmrc, pip.conf, poetry config, Docker login ou les workflows de publication, cette modification doit être traitée comme sensible. Le test le plus simple consiste à reproduire la build dans un environnement propre et à observer d’où sont téléchargés les paquets : une build qui fonctionne sur l’ordinateur du développeur mais utilise des sources différentes en CI n’est pas gouvernable.

Registres, jetons et identifiants de publication

La supply chain signifie aussi qui peut télécharger et publier. Les jetons npm, PyPI, GitHub Packages, Docker registry, les registres de paquets privés et les identifiants CI/CD doivent avoir un périmètre minimal. Un agent ayant accès au terminal ou au pipeline peut lire ou utiliser des jetons si l’environnement n’est pas correctement séparé.

Il faut vérifier où résident les jetons de registre, qui peut publier, quelles branches activent les releases, quels paquets sont privés, quels espaces de noms sont protégés et quels logs peuvent imprimer des identifiants. Si l’IA modifie les workflows de publication ou de versioning, cette modification est sensible et nécessite une révision explicite. Pour les paquets internes, protéger le nommage et les espaces de noms est fondamental : un import ambigu ou une mauvaise configuration de registre peut mener à une confusion de dépendances, le système de build téléchargeant un paquet public au lieu du paquet interne prévu.

SBOM, provenance et traçabilité

Si l’on ne sait pas ce qui est entré dans la build, il est impossible de le gérer dans le temps. Une Software Bill of Materials (SBOM) aide à lister les composants, les versions et les dépendances. CycloneDX est un standard consolidé pour représenter les SBOM, tandis qu’OpenSSF SLSA fournit un cadre pour réfléchir à la provenance et à l’intégrité de la build.

Pour un petit MVP, une SBOM peut sembler excessive, mais pour un produit destiné à des clients, un SaaS avec des données réelles ou un éditeur de logiciels qui livre du code, elle devient un outil pratique : lorsqu’une CVE sort, lorsqu’un client demande des preuves ou lorsqu’une dépendance est compromise, savoir ce qui est inclus dans la release réduit les délais et l’incertitude. Les agents IA augmentent le besoin de traçabilité car ils peuvent ajouter et changer des composants fréquemment. Sans SBOM ou inventaire des dépendances, l’équipe dépend de la mémoire de celui qui a accepté le diff.

Scanners automatiques : nécessaires, mais pas suffisants

SCA, analyse des dépendances, analyse des conteneurs et analyse des licences sont des contrôles indispensables : ils interceptent les vulnérabilités connues, les licences problématiques et les versions obsolètes. Ils ne répondent cependant pas à toutes les questions de sécurité pertinentes.

Un scanner n’évalue pas si cette dépendance est vraiment nécessaire, si un paquet quasi homonyme a été choisi par erreur, si un script postinstall est cohérent avec la politique de l’entreprise, si le lockfile a été régénéré sans raison, si une licence est acceptable pour ce client ou si la build télécharge du code de manière non reproductible. C’est pourquoi la revue de la supply chain doit combiner des outils automatiques et le jugement humain : le scanner donne des signaux, mais la décision de fusion nécessite du contexte.

Surveillance après la fusion

La supply chain ne s’arrête pas à la fusion. Une dépendance propre aujourd’hui peut recevoir une CVE demain, changer de mainteneur, introduire une version compromise ou devenir incompatible avec un correctif de sécurité. C’est pourquoi il est nécessaire de savoir quels composants sont en production et qui possède la remédiation.

La surveillance doit relier la SBOM, les scanners, la gestion des vulnérabilités, le suivi des tickets et les releases. Lorsqu’une vulnérabilité émerge, l’équipe doit comprendre rapidement si le composant est présent, dans quelle version, dans quel service, s’il est accessible, s’il existe un exploit actif, quelle atténuation appliquer et qui doit approuver la mise à jour. Les agents IA peuvent aider à préparer les mises à jour, mais ne devraient pas les appliquer sans revue : une mise à jour automatique peut corriger une CVE et casser l’authentification, le parsing, la sérialisation, l’upload ou la compatibilité d’exécution. Le patch doit être traité comme une modification de produit, pas comme un simple ménage.

Quand le paquet touche à la sécurité applicative

Certaines dépendances nécessitent une attention accrue car elles entrent directement dans les périmètres de sécurité : bibliothèques d’authentification, JWT, crypto, assainissement HTML, moteurs de template, analyseurs markdown, upload, validation des entrées, ORM, pilotes de base de données, clients HTTP, middleware CORS, limitation de débit (rate limiting), journalisation et gestion des secrets.

Si l’IA remplace ou reconfigure l’une de ces bibliothèques, la revue doit également lire le comportement applicatif. Un nouvel analyseur peut changer la gestion XSS ; un middleware CORS peut ouvrir des domaines non prévus ; une mise à jour d’ORM peut modifier des requêtes ou l’échappement ; un paquet d’upload peut accepter des types MIME ou des chemins de manière différente ; une bibliothèque JWT peut nécessiter des configurations explicites sur l’algorithme, l’audience ou l’émetteur. Ces dépendances ne doivent pas être approuvées simplement parce qu’elles n’ont pas de CVE connues : la question est de savoir si elles sont configurées correctement pour le produit. C’est ici que la supply chain et la sécurité applicative se rencontrent.

Commandes générées automatiquement par les agents

Lorsqu’un agent a accès au terminal, il peut exécuter des installations, des mises à jour, des migrations, des tests, des scripts de build, des commandes cloud et des modifications de configuration. Le journal des commandes devient partie intégrante de la revue : il ne suffit pas de regarder le code final, il faut savoir ce qui a été exécuté.

Une commande peut modifier des fichiers non attendus, mettre à jour des lockfiles, installer des paquets globaux, changer des configurations locales, générer des artefacts, créer des caches ou envoyer des données à des services externes. Dans les environnements avec des secrets, des jetons ou des identifiants cloud, le risque augmente davantage. Pour les agents opérationnels, il est nécessaire de définir des listes blanches de commandes, d’exiger une approbation pour les installations et les déploiements, d’utiliser des environnements sandbox, des jetons avec un périmètre minimal et de conserver les logs. Si l’agent installe des paquets sans approbation, le processus de revue commence déjà en retard.

Politique de fusion pour les dépendances générées par l’IA

Une politique efficace ne doit pas bloquer chaque changement, mais rendre les décisions explicites. Chaque nouvelle dépendance proposée ou installée par l’IA devrait indiquer : motif, gestionnaire de paquets, version, licence, mainteneur, alternatives considérées, impact sur le lockfile, résultats SCA, scripts éventuels et propriétaire interne.

Les dépendances à haut risque devraient exiger une approbation explicite : paquets non maintenus, bibliothèques avec peu de téléchargements, wrappers de sécurité, analyseurs, moteurs de template, gestionnaires d’upload, crypto, authentification, mise en réseau, paquets exécutant des scripts, nouvelles images de base et outils entrant dans la CI/CD. Pour les équipes qui utilisent le codage IA de manière continue, cette politique devient partie intégrante du cycle de vie de l’assurance logicielle (Software Assurance Lifecycle) : il n’est pas nécessaire de faire une exception à chaque fois, mais d’avoir un parcours reproductible pour installer, évaluer, approuver et surveiller.

Comment ISGroup vérifie la supply chain et les dépendances générées par l’IA

ISGroup peut vérifier une PR, un dépôt ou un processus de mise en production dans lequel des agents IA modifient des dépendances, des lockfiles, des Dockerfiles, des workflows, des scripts ou des registres de paquets. Le contrôle concerne à la fois le code et la chaîne qui l’amène en production.

Si l’IA a modifié…	Risque principal	Contrôle conseillé
Manifeste, lockfile, paquet, script, Dockerfile ou arbre de dépendances	Dépendances vulnérables, inutiles ou non gouvernées	Code Review
Composants, services, bibliothèques et versions exposés en ligne	Vulnérabilités connues exploitables	Vulnerability Assessment
Dépendances et composants en production à surveiller dans le temps	Vulnérabilités récurrentes et gestion des correctifs	Vulnerability Management Service
Pipeline, politique de fusion, contrôles SCA, SBOM et portes de sortie	Processus non reproductible sur les releases	Software Assurance Lifecycle
Cloud, registre de conteneurs, IAM, jetons, artefacts et déploiement	Mauvaise configuration ou privilèges excessifs	Cloud Security Assessment

Le choix du contrôle dépend du point où le risque entre : code et manifeste, composants exposés, processus de patching, pipeline ou cloud. Avant la fusion, il est préférable de savoir si le paquet est vraiment nécessaire et si la build reste gouvernable. Si vous avez une PR générée par l’IA qui ajoute des paquets, modifie des lockfiles ou change des pipelines, ISGroup peut vous aider à vérifier les dépendances, les scripts, les conteneurs, la SBOM et les contrôles de fusion avant la release.

Preuves à préparer pour une vérification

Pour lancer une vérification efficace, il est utile de rassembler : dépôt, branche, PR, manifeste, lockfile, arbre de dépendances, Dockerfile, workflow CI/CD, scanners utilisés, rapports SCA, rapport de licence, SBOM si présente, commandes exécutées par l’agent, jetons impliqués, registres utilisés et motivation des nouvelles dépendances.

Pour chaque paquet ajouté, il est utile de documenter : nom, version, registre, mainteneur, dépôt, licence, alternatives disponibles, motif technique, dépendances transitives, scripts d’installation et propriétaire interne. Si l’agent a exécuté des commandes, il est important de conserver les logs et les sorties. Ces preuves permettent de distinguer une dépendance nécessaire d’un raccourci généré, un risque bloquant d’une mise à jour planifiable, et une vulnérabilité connue d’un problème de processus.

Quand bloquer la fusion

Bloquez la fusion si une nouvelle dépendance est suspecte, inutile, non maintenue, avec une licence incompatible, avec des scripts non vérifiés, avec une vulnérabilité critique non atténuée, avec un lockfile trop large sans explication ou si le pipeline a été modifié pour contourner les contrôles.

Vous pouvez planifier après la fusion uniquement les activités à risque résiduel faible : améliorer la documentation, générer une SBOM si la mise en production n’est pas imminente, affiner les politiques, ajouter des modèles d’analyse ou réduire les dépendances non critiques avec un propriétaire et une échéance. Les dépendances qui exécutent du code, touchent à la sécurité ou entrent en production doivent être claires avant.

Checklist supply chain pour les PR générées par des agents

• Chaque nouvelle dépendance a un motif, un propriétaire et une alternative évaluée.
• Le manifeste et le lockfile sont révisés ensemble.
• Le nom du paquet, le mainteneur, le registre et le dépôt sont vérifiés.
• Les scripts preinstall, install, postinstall, prepare et de build sont contrôlés.
• L’analyse SCA, l’analyse des licences et l’analyse des conteneurs sont effectuées.
• Les versions et les images de base ont un verrouillage explicite, sans latest non motivé.
• SBOM générée ou mise à jour lorsque le produit l’exige.
• Les jetons de registre et de CI/CD ont un périmètre minimal.
• Les commandes exécutées par l’agent sont journalisées et approuvées là où c’est nécessaire.
• Les dépendances générées par l’IA passent par une revue obligatoire avant la fusion.

Questions fréquentes

• Si le scanner SCA est propre, puis-je accepter la dépendance ?
• Pas automatiquement. Le scanner n’évalue pas la nécessité, la licence, le mainteneur, le typosquatting, les scripts d’installation, la cohérence du lockfile et l’impact sur le produit. C’est un outil de support, pas un feu vert.
• Le lockfile doit-il vraiment être révisé ?
• Oui. Le lockfile montre ce qui entre réellement dans la build, y compris les dépendances transitives et les mises à jour indirectes qui n’apparaissent pas dans le manifeste.
• Un agent peut-il installer des paquets tout seul ?
• Il peut le faire seulement si le processus l’autorise. Dans les projets avec des données réelles ou en production, les installations et les commandes qui modifient les dépendances devraient exiger une approbation explicite et des logs conservés.
• Quand une SBOM est-elle nécessaire ?
• Lorsque vous devez livrer des logiciels, répondre à des clients entreprises, gérer des vulnérabilités dans le temps ou savoir rapidement si une CVE concerne une release spécifique.
• Qu’est-ce qui change par rapport à une Code Review normale ?
• La Code Review lit le code. La revue de la supply chain lit aussi les manifestes, les lockfiles, les scripts, les registres, les conteneurs, la SBOM, les licences, les commandes exécutées et les pipelines.
• Quand le Vulnerability Management Service est-il nécessaire ?
• Lorsque le problème n’est pas seulement de contrôler une PR, mais de surveiller continuellement les composants, les versions et les vulnérabilités en production dans le temps.

[Callforaction-WAPT-Footer]

Sources et références utiles

• OWASP Dependency-Check: https://owasp.org/www-project-dependency-check/
• OWASP CycloneDX: https://owasp.org/www-project-cyclonedx/
• OpenSSF Scorecard: https://openssf.org/scorecard/
• OpenSSF SLSA: https://openssf.org/projects/slsa/
• OWASP SAMM: https://owasp.org/www-project-samm/
• OWASP Top 10 – Vulnerable and Outdated Components: https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/