Comment l’IA révèle les limites du contrôle manuel des dépendances

Les outils de codage par IA rendent impossible à ignorer un problème bien connu de la chaîne d’approvisionnement logicielle : la confiance dans les dépendances repose encore largement sur des contrôles qui interviennent après que les développeurs ont choisi quoi utiliser. Les assistants et les agents peuvent intégrer des packages, des bibliothèques et des images de conteneur dans une base de code plus vite qu’une équipe de sécurité ne peut les examiner. La revue humaine ne peut pas corriger ce décalage de timing en allant simplement plus vite. La décision de sécurité doit se rapprocher du point où les dépendances entrent dans le développement.

L’IA met en lumière un modèle de sécurité qui était déjà trop lent

Ce problème de timing commence avec un modèle de développement construit autour d’une sélection humaine délibérée. Les anciennes pratiques de composition logicielle supposaient qu’un développeur avait choisi une bibliothèque, peut-être parce qu’il l’avait déjà utilisée, et pouvait expliquer ce choix lors de la revue. Les processus d’approbation en entreprise se sont développés à ce rythme, avec des cycles de revue mesurés en jours. Le développement agentique, où des systèmes d’IA exécutent des tâches de développement avec une plus grande autonomie, réduit ou supprime la pause pendant laquelle ces contrôles opéraient auparavant.

Avec moins de temps disponible, l’approbation manuelle devient un goulot d’étranglement, car la génération instantanée de code continue d’alimenter des processus conçus pour un développement plus lent. « La vitesse a dépassé la gouvernance et les contrôles », déclare Quincy Castro, CISO chez Chainguard, une entreprise de sécurité de la chaîne d’approvisionnement logicielle. Chainguard vend une technologie destinée à sécuriser les chaînes d’approvisionnement logicielles ; l’entreprise a donc un intérêt commercial à ce que les organisations renforcent les contrôles sur l’origine des dépendances.

Castro relie directement cet écart de vitesse à la manière dont le travail parvient aux équipes de sécurité. « Quand vous pouvez générer du code instantanément, le cycle traditionnel de demande, revue et approbation crée des goulots d’étranglement. Personne n’acceptera un monde où il accomplit son travail très rapidement et où tout s’empile ensuite face à un processus hérité, manuel et piloté par l’humain », explique Castro. Maintenir le même point d’approbation tout en augmentant le volume qui y arrive laisse la sécurité fonctionner au rythme de développement d’hier.

Ce décalage accélère une faiblesse que Castro dit avoir observée dans quatre postes de CISO. Les équipes d’ingénierie sont passées d’une idée sur un tableau blanc à un produit minimum viable avant d’impliquer la sécurité pour l’approbation finale. À ce stade, elles ont déjà fait les choix technologiques et les ont assemblés dans un système fonctionnel. La sécurité se retrouve à valider un résultat après qu’une grande partie des décisions d’approvisionnement déterminantes a déjà été prise.

La revue tardive se heurte aussi à une limite de connaissance à mesure que le nombre de stacks technologiques augmente. « L’idée qu’une petite équipe de sécurité puisse être spécialiste de chaque stack technologique d’une organisation du Fortune 500, et puisse dire oui ou non, cette chose peut être mise en production en toute sécurité, est ridicule », affirme Castro. Un petit groupe qui prend les décisions finales à l’échelle d’une grande entreprise doit comprendre des composants sélectionnés par de nombreuses équipes sur des stacks qui peuvent avoir très peu en commun.

Ce problème de connaissance est antérieur aux agents de codage, raison pour laquelle Castro voit l’IA comme un accélérateur d’une faiblesse existante. « Je doute que la plupart des équipes de sécurité aient jamais réellement examiné et validé efficacement les composants logiciels utilisés par les développeurs. C’est pour cela que la chaîne d’approvisionnement logicielle est devenue une cible aussi attrayante. Si nous étions déjà mauvais dans ce domaine auparavant, ajouter par-dessus la vitesse et l’échelle du développement agentique ne fait qu’aggraver les choses », déclare Castro. Les garde-fous existants devaient déjà compenser des jugements faibles sur l’approvisionnement ; le développement agentique laisse à ces garde-fous encore moins de temps pour le faire.

Le choix de dépendances à la vitesse machine élargit la surface d’attaque

Une fois qu’un logiciel peut sélectionner des dépendances pendant la génération, trouver du code pertinent et établir sa qualité de sécurité deviennent deux tâches distinctes. Un agent peut trouver un package qui semble pertinent pour un prompt sans établir si son projet est activement maintenu ou si son circuit de distribution reste digne de confiance. Des composants légitimes, des packages malveillants, des bibliothèques typosquattées et des dépendances transitives compromises peuvent tous arriver par les mêmes mécanismes automatisés de dépendance ; l’adéquation fonctionnelle seule n’établit donc pas la confiance.

Les attaquants peuvent exploiter cet écart en ciblant des parties de l’open source qui reçoivent moins d’attention. Les projets populaires ont tendance à attirer davantage de mainteneurs, davantage de contributeurs qui examinent les changements, et davantage de surveillance automatisée, ce qui augmente les chances que des modifications malveillantes soient repérées. « Introduire discrètement un malware dans le dépôt ouvert et publiquement visible d’un projet open-source populaire n’est probablement pas la voie du succès, sauf s’ils sont extrêmement furtifs », explique Castro. Les projets qui attirent moins l’attention offrent aux attaquants un environnement opérationnel différent.

Cette différence peut façonner à la fois la compromission et la distribution. « Ils s’attaquent donc aux projets moins bien maintenus, puis trouvent des moyens d’orienter les développeurs vers ces projets afin d’obtenir la diffusion maximale pour leur opération », explique Castro. Lorsque les agents et les développeurs choisissent dans un vaste univers de dépendances, un package obscur peut répondre à une requête fonctionnelle tout en bénéficiant d’une revue externe nettement moindre qu’un projet bien connu.

Une opération récente citée par Castro montre comment les attaquants peuvent aussi exploiter l’identité d’un projet. Les attaquants ont produit de nombreux forks de projets légitimes, y ont inséré des malwares, puis les ont diffusés assez largement pour que des développeurs les confondent avec les dépôts officiels. Une telle erreur pourrait introduire directement des capacités d’attaque dans un pipeline d’intégration continue et de livraison continue (CI/CD), le processus automatisé qui construit, teste et prépare les logiciels pour leur mise en production.

Même une large adoption ne peut pas éliminer la compromission, comme le montre l’attaque contre Trivy. Dans l’attaque de mars contre Trivy que Castro cite, des attaquants ayant pris le contrôle des GitHub Actions du scanner ont forcé la mise à jour de 75 de ses 76 tags de version pour qu’ils pointent vers des commits contenant un infostealer. GitHub Actions automatise les workflows de dépôt ; le contrôle de ces références a donc donné au code malveillant une voie d’accès à l’activité automatisée autour d’un outil de sécurité largement utilisé.

La compromission de Trivy a ensuite propagé le risque au-delà du dépôt d’origine. Les attaquants ont récolté des secrets et les ont utilisés pour publier des packages npm malveillants, faisant passer l’opération d’une partie de l’écosystème logiciel à une autre. Parmi les autres techniques du même paysage de menaces figurent le typosquatting, où des packages malveillants utilisent des noms volontairement très proches ; la prise de contrôle de comptes de mainteneurs ; des points de distribution empoisonnés ; et le dependency riding, où les attaquants exploitent les relations de dépendance héritées d’un logiciel.

Ces techniques deviennent plus lourdes de conséquences à mesure que la sélection automatisée crée davantage d’occasions de rencontrer une dépendance candidate. N’importe qui peut publier un logiciel open-source, tandis que son inclusion dans un système d’entreprise peut affecter des systèmes bien au-delà de la fonction qui a initialement conduit à sélectionner un package. La sélection à la vitesse machine répète cette décision de confiance sur un plus grand nombre de dépendances avec moins de revue délibérée, ce qui rend importante la répartition du risque dans l’écosystème.

Le risque se concentre dans la longue traîne

Cette répartition explique pourquoi une petite liste de composants approuvés ne peut pas couvrir l’ensemble du problème. Les données State of Trusted Open Source de Chainguard mesurent les vulnérabilités et expositions communes (CVE) sur les images de conteneur et signalent une forte concentration en dehors des 20 images les plus populaires. Comme Chainguard vend une technologie de sécurité de la chaîne d’approvisionnement logicielle, cette mesure provient d’une entreprise ayant un intérêt commercial dans des contrôles de sécurité des dépendances plus larges.

Ces chiffres vont à l’encontre de la manière dont les efforts de durcissement en entreprise sont souvent alloués. Les entreprises peuvent consacrer des ressources importantes à une collection relativement restreinte d’images largement utilisées, parce qu’elles affectent de nombreuses charges de travail et donnent aux équipes de sécurité une cible gérable. Les données de mars 2026 de Chainguard situent 3,8 % des CVE à l’intérieur de ce groupe populaire, tandis que l’édition de juin en rapporte 97 % en dehors du top 20.

Castro interprète cette répartition comme une inversion de l’attention portée par les entreprises. « La concentration du risque est inversée par rapport à l’endroit où se porte l’essentiel de l’attention des entreprises », explique Castro. « Les organisations consacrent énormément de ressources au durcissement d’un petit ensemble d’images bien connues et largement utilisées, alors que l’exposition réelle se trouve dans la longue traîne. » Chainguard fournit à la fois l’ensemble de données et l’interprétation de Castro ; les chiffres et la conclusion sont donc des affirmations d’un fournisseur dont l’activité bénéficie d’une couverture plus large de la sécurité de la chaîne d’approvisionnement.

La longue traîne compte davantage pour le développement lorsque l’IA peut faire remonter des logiciels que les ingénieurs n’auraient jamais retrouvés de mémoire. Un composant peut être pris en considération simplement parce qu’il correspond à un prompt, offrant aux dépendances obscures une autre voie d’entrée dans les workflows de développement. À mesure que la population de dépendances accessibles s’élargit, une gouvernance concentrée sur les composants les plus familiers couvre une part plus faible de ce que les équipes et les agents peuvent sélectionner.

La standardisation sur des composants populaires peut encore réduire le risque partout où ces composants sont déployés, et leur popularité peut favoriser une maintenance et une surveillance plus solides. La répartition des CVE citée par Chainguard place toutefois l’essentiel de la population de vulnérabilités mesurée ailleurs. Une gouvernance construite autour d’un petit noyau doit donc tenir compte de la population bien plus vaste qui se trouve au-delà.

Cette population plus large contient aussi des dépendances dont les applications peuvent réellement avoir besoin. Les applications réelles peuvent dépendre de logiciels spécialisés avec peu de mainteneurs, tandis que des systèmes legacy peuvent s’appuyer sur des composants qui ne peuvent pas être facilement mis à niveau ou remplacés. Ces cas font de la longue traîne une exigence opérationnelle autant qu’un sujet de sécurité, tandis que les dépendances héritées rendent cette population plus difficile à voir.

Une partie du risque lié aux dépendances disparaît avant même d’apparaître dans l’inventaire

Le problème de visibilité s’aggrave parce que les dépendances directes d’une application ne sont que la première couche de code impliquée dans la création d’un logiciel. Un package peut dépendre d’autres packages, qui apportent à leur tour leurs propres dépendances. Castro explique que les développeurs peuvent perdre toute visibilité pratique au bout de deux ou trois niveaux dans cette chaîne, même si le processus de build peut toujours exécuter le code hérité.

Castro décrit une détection où cette différence a d’abord donné l’impression que le malware était incohérent avec l’artefact final. « Nous avons eu des détections qui se sont déclenchées pour une dépendance contenant un malware, et nous avons constaté qu’elle n’était pas présente dans l’image de conteneur, ou pas dans la nomenclature logicielle », dit-il. Une nomenclature logicielle (SBOM) est un inventaire des composants associés à un logiciel, mais un inventaire de l’artefact résultant ne peut pas, à lui seul, représenter tout ce qui a été exécuté temporairement pendant la production de cet artefact.

L’enquête a montré où la dépendance manquante était apparue. « Ensuite, nous rembobinons le film et voyons qu’il s’agissait d’une dépendance d’une dépendance transitive qui s’est brièvement exécutée pendant un build. Était-ce réel ? Oui. Une personne normale qui construirait cela aurait-elle le moindre signe qu’elle était exposée à un risque ? Absolument pas. » La dépendance malveillante avait une exposition réelle à l’exécution même si elle n’a pas subsisté dans l’image de conteneur résultante ni n’est apparue dans sa nomenclature logicielle.

Ce cas distingue la visibilité de l’état final de l’exposition au moment du build, car les deux répondent à des questions de sécurité différentes. Un SBOM peut fournir des informations utiles sur les composants associés à un artefact, tandis que des dépendances temporaires peuvent causer des dommages avant même que l’artefact n’existe. Un processus de sécurité centré sur ce qui reste à la fin peut donc passer à côté de code qui a participé à la production du logiciel.

Couvrir cet écart exige des systèmes de chaîne d’approvisionnement capables de contrôler des couches de logiciels hérités. Castro affirme que les organisations peuvent construire elles-mêmes de tels systèmes avec des investissements suffisants, mais que le passage à l’échelle devient difficile, car produire des packages open-source dignes de confiance exige plus que de vérifier chaque dépendance directe isolément. La croissance des dépendances pilotée par l’IA augmente la charge sur cette infrastructure, tandis que le comportement transitoire au moment du build rend les inventaires d’artefacts incomplets et pousse davantage de détections vers les systèmes de détection en aval.

Davantage de scans déplacent le goulot d’étranglement vers l’aval

Lorsque davantage de dépendances atteignent la détection en aval, des scanners supplémentaires peuvent trouver plus de problèmes, mais chaque problème détecté crée du travail ailleurs dans la chaîne de livraison. « Faire davantage des mêmes choses qui, traditionnellement, n’ont jamais très bien fonctionné, à une vitesse et à une échelle bien supérieures, signifie que vous avez échoué avant même d’avoir commencé », déclare Castro. Son argument porte sur la capacité de remédiation derrière la détection, car découvrir une vulnérabilité supplémentaire n’aide que lorsque l’organisation peut décider quoi en faire et faire appliquer cette décision.

Les pratiques existantes de gestion des vulnérabilités montrent déjà cette contrainte de capacité. « Les entreprises ont déjà du mal à corriger les vulnérabilités sévères, sans parler de toutes les vulnérabilités moyennes et élevées qu’elles acceptent régulièrement comme risque. Plus de scans et plus de correctifs ne tiendront pas face à un volume géométriquement plus important de code développé par des agents », affirme Castro. L’acceptation existante du risque pour les détections de niveau moyen et élevé montre que les organisations trient déjà les résultats ; davantage de code généré augmente donc la quantité qu’elles doivent classer, corriger ou accepter.

Les outils d’application des règles peuvent transformer ces détections non résolues en travail d’ingénierie bloqué. Les pare-feu pour développeurs et les politiques qui cassent les builds peuvent arrêter une dépendance après que le choix d’approvisionnement est déjà entré dans le flux de développement, laissant les développeurs chercher pourquoi une pull request ne peut pas avancer. Une file d’attente de sécurité devient alors une file d’attente d’ingénierie, près du point où l’équipe s’attendait à livrer.

Ce transfert impose un coût direct sur la livraison. « Les ingénieurs finissent par gérer tout un tas de builds cassés alors que ce qu’ils veulent faire, c’est livrer des produits que les gens aiment, pas diagnostiquer pourquoi un scanner dit qu’ils ne peuvent pas pousser leur PR », explique Castro. Les scans, les correctifs et les contrôles de build restent des défenses utiles, mais augmenter leur charge de travail tout en laissant entrer le même volume d’entrées risquées maintient le décalage entre une sélection rapide des dépendances et une remédiation plus lente.

Le secure-by-default doit couvrir la longue traîne

Réduire cette charge de travail en aval exige de changer les conditions dans lesquelles les dépendances entrent dans le développement. Castro préconise des composants open-source reconstruits avec des attestations de provenance, c’est-à-dire des enregistrements montrant où et comment un artefact a été produit, ainsi qu’une surface d’attaque réduite et une maintenance continue. Chainguard vend des produits de sécurité de la chaîne d’approvisionnement logicielle alignés sur ce modèle ; l’entreprise en bénéficie donc commercialement si les organisations adoptent ce type d’approche en amont.

Avec ces contrôles appliqués plus tôt, la provenance peut éclairer la sélection, tandis que la maintenance continue peut couvrir les changements après l’approbation initiale. Les composants et les systèmes qui les fournissent sont sécurisés de manière systématique avant que des applications individuelles ne les assemblent, ce qui réduit le nombre de problèmes que les scanners et les barrières de mise en production doivent renvoyer aux développeurs ou aux équipes de sécurité pour une résolution manuelle. L’approche déplace le travail d’une remédiation répétée au niveau des applications vers le processus d’approvisionnement des dépendances.

Ce processus d’approvisionnement doit néanmoins couvrir des besoins irréguliers dans toute la longue traîne. « Il y a toujours un cas limite bizarre ou une exception. Il y a toujours un système qui ne peut pas être correctement mis à jour, toujours une application qui exige une chose étrange maintenue par une seule personne », explique Castro. De tels cas se situent dans la partie de l’écosystème qui reçoit moins de surveillance collective et que les chiffres de CVE de Chainguard identifient comme portant l’essentiel de l’exposition mesurée.

Le même problème de couverture dépasse les équipes d’ingénierie conventionnelles avec le citizen development, où des employés hors des équipes logicielles créent des applications pour leur propre travail. Un analyste financier peut faire du vibe coding, c’est-à-dire créer un logiciel par prompting assisté par IA, dans un environnement de développement intégré assisté par IA sans qu’une équipe de site reliability engineering (SRE) ou des spécialistes de la sécurité applicative (AppSec) n’examinent le résultat. La revue spécialisée est la plus difficile à appliquer dans ce workflow, car la sélection des dépendances peut se produire immédiatement alors qu’aucun expert sécurité dédié n’y participe.

Un accès plus large à la création logicielle fait donc de la couverture des dépendances la contrainte pratique de la gouvernance en amont. Les entreprises rencontreront toujours des packages obscurs, des systèmes legacy, des composants spécialisés et des exceptions ; le système d’approvisionnement doit donc gérer ces cas au fur et à mesure qu’ils apparaissent. Castro formule l’exigence ainsi : « L’idée que nous pouvons orienter tout le monde vers les choses les plus populaires est séduisante en théorie et très difficile à mettre en pratique. Pour moi, cela plaide en faveur d’un basculement vers des composants et des systèmes systématiquement sécurisés par défaut, plutôt que de laisser les gens faire n’importe quoi puis d’essayer de résoudre le problème juste avant que nous passions en production », déclare Castro.

Points clés à retenir pour les décideurs

• Déplacez les contrôles sur les dépendances en amont : Les outils de codage par IA sélectionnent et introduisent des dépendances plus vite que les revues de sécurité manuelles ne peuvent les évaluer. Les équipes sécurité et plateforme peuvent établir la confiance au plus près de l’approvisionnement afin que l’approbation ne devienne pas un goulot d’étranglement pour la livraison.
• Gouvernez la sélection de dépendances à la vitesse machine : Les agents de codage peuvent faire remonter des packages obscurs, compromis ou malveillants sur la base de leur adéquation fonctionnelle. Les organisations d’ingénierie ont besoin de contrôles de provenance et d’approvisionnement qui évaluent la confiance avant que ces composants n’entrent dans les workflows de développement.
• Couvrez la longue traîne logicielle : Chainguard indique que 97 % des CVE mesurées sur les images de conteneur dans ses données de juin se situaient en dehors des 20 images les plus populaires. Les programmes de gestion des dépendances doivent couvrir les composants spécialisés et moins maintenus, en plus des logiciels largement utilisés.
• Suivez les dépendances au moment du build : Les dépendances transitives peuvent s’exécuter pendant les builds et disparaître avant que l’image de conteneur finale ou le SBOM ne soit créé. Les équipes plateforme et sécurité ont besoin de contrôles qui observent et gouvernent le processus de build ainsi que les artefacts finaux.
• Réduisez la pression de remédiation en aval : Davantage de scans créent davantage de détections que les équipes d’ingénierie et de sécurité doivent examiner, corriger, accepter ou bloquer. Les organisations peuvent réduire cette charge de travail en améliorant la confiance dans les dépendances avant que les composants n’atteignent les barrières de mise en production.
• Faites des composants sécurisés le choix par défaut : Les attestations de provenance, des surfaces d’attaque réduites et une maintenance continue peuvent déplacer le travail de sécurité vers le processus d’approvisionnement des dépendances. Les équipes plateforme ont besoin de ce modèle pour couvrir les systèmes legacy, les cas limites et le développement assisté par IA en dehors des équipes d’ingénierie traditionnelles.