Supply chain logicielle : l'IA peut-elle briser le cercle vicieux ?

En août 2026, un seul compte de mainteneur compromis a suffi au ver ChainDrop pour contaminer des centaines de paquets npm

Dépendances, vers et provenance : ce que l'IA change vraiment

De xz-utils à ChainDrop, les attaques sur la chaîne d'approvisionnement logicielle se succèdent et se perfectionnent. Le jour même où nous publiions notre volet consacré aux défenseurs, le 12 mai, une nouvelle vague touchait TanStack, Mistral AI et plus de 160 paquets npm et PyPI. Pour ce dernier volet de la série, nous regardons ce que l'IA apporte à la détection, ce qu'elle ne règle pas, et ce que le Cyber Resilience Act impose depuis septembre.

Anatomie des attaques récentes

L'affaire xz-utils (CVE-2024-3094) reste le cas d'école. Sous le pseudonyme « Jia Tan », un acteur malveillant a passé près de deux ans à gagner la confiance de la communauté, jusqu'à obtenir les droits de mainteneur du projet grâce à une pression sociale méthodique sur le mainteneur historique. La porte dérobée, notée 10 sur l'échelle CVSS, visait l'authentification SSH. Andres Freund, ingénieur chez Microsoft, l'a repérée en mars 2024 en s'étonnant d'une latence anormale de ses connexions SSH. Elle avait déjà atteint les versions de développement de plusieurs distributions, dont Fedora et Debian, et a été stoppée de justesse avant d'entrer dans leurs versions stables.

Le cas polyfill.io relève d'un autre mécanisme. En février 2024, le domaine de ce service JavaScript très répandu est racheté par la société chinoise Funnull. Quelques mois plus tard, le script servi à plus de 100 000 sites se met à rediriger les visiteurs mobiles vers des sites frauduleux. Censys recense alors 384 773 hôtes qui y font encore appel. Fin juin 2024, le domaine est suspendu, et Cloudflare comme Fastly proposent des miroirs sains.

L'année 2026 a montré que le modèle passe à l'échelle industrielle. En avril, CanisterSprawl se propageait déjà grâce à des jetons npm volés aux développeurs. Le groupe TeamPCP a ensuite enchaîné les vagues : paquets SAP fin avril, PyTorch Lightning le 30 avril, puis TanStack, Mistral AI, UiPath et plus de 160 autres paquets le 12 mai. En août, ChainDrop a franchi un nouveau palier. Parti du compte GitHub compromis du mainteneur de Keyv, le ver récupère des jetons de publication, injecte son code dans tous les paquets accessibles à l'identité volée, incrémente leur version et les republie. Microsoft en a dénombré plus de 400, d'autres chercheurs bien davantage. Détail troublant : publiées via les workflows GitHub Actions légitimes, les versions piégées portaient des attestations de provenance valides.

En toile de fond, le groupe nord-coréen Lazarus poursuit ses campagnes de faux paquets npm visant les développeurs. Sonatype avait déjà recensé plus de 500 000 paquets malveillants en 2024, en hausse de 156 % sur un an.

La détection IA : au-delà des CVE connues

Ces attaques ont un point commun : aucune ne correspond à une CVE au moment où elle frappe. Les scanners classiques, qui comparent les dépendances à des bases de vulnérabilités connues, ne voient rien passer. C'est précisément sur ce terrain que l'IA apporte le plus.

Socket.dev a bâti son approche sur l'analyse comportementale des paquets : accès réseau inattendus, scripts d'installation, code obfusqué, typosquatting. L'entreprise a levé 40 millions de dollars en octobre 2024. Côté recherche, Cerebro, publié en 2025, entraîne un modèle de langage sur des séquences de comportements malveillants communes à npm et PyPI. L'outil a permis d'identifier 683 nouveaux paquets malveillants sur PyPI et 799 sur npm, et ses auteurs ont reçu 707 remerciements des équipes des registres. TypoSmart, présenté en février 2025, compare les noms de paquets par embeddings pour repérer les imitations : sur 3 658 noms suspects signalés, 86,1 % contenaient effectivement du code malveillant.

Les vers de 2026 rappellent pourtant les limites de l'exercice. Quand un attaquant publie depuis le compte et le pipeline légitimes du mainteneur, le paquet n'a ni nom suspect ni origine douteuse. Seul le comportement du nouveau code trahit l'intrusion, et la course se joue en heures : chaque installation automatique dans une chaîne d'intégration continue étend la contamination.

SBOM et provenance : la transparence ne suffit plus

La nomenclature logicielle (SBOM) s'est imposée comme la base de toute démarche sérieuse, car il faut savoir ce qu'on embarque avant de pouvoir dire si on est touché. L'IA aide à la produire et à la tenir à jour, en identifiant composants, versions et licences jusque dans les dépendances transitives. Pour les systèmes d'IA eux-mêmes, l'AIBOM étend l'exercice aux modèles, aux jeux de données et aux embeddings utilisés.

Les cadres de provenance comme SLSA vont plus loin en attestant comment et où un artefact a été construit. Ils bloquent efficacement la confusion de dépendances et les paquets publiés hors du circuit officiel. ChainDrop montre leur angle mort : une attestation prouve que le paquet sort du bon pipeline, pas que ce pipeline n'a pas été détourné. La provenance reste nécessaire, mais elle ne suffit plus sans surveillance du comportement et sans protection forte des comptes et des jetons de publication.

Recoder ses dépendances : la fausse bonne idée ?

Face à ces risques, une stratégie radicale gagne du terrain : internaliser les dépendances critiques en les recodant, ce que les assistants de code rendent soudain bon marché. Andrej Karpathy l'assumait au printemps : plutôt que d'empiler les dépendances, il préfère demander à un LLM de reprendre la fonctionnalité quand elle est assez simple. L'idée a gagné du terrain après les alertes LiteLLM et Axios du printemps 2026.

Drew Breunig, dont nous citions l'analyse dans le volet précédent, en tire la conclusion inverse. Si la sécurité devient une affaire de tokens dépensés à chercher des failles, une bibliothèque open source largement utilisée profite des efforts de tous ses utilisateurs, alors qu'une réimplémentation maison ne dispose que du budget de son auteur. La loi de Linus, selon laquelle tous les bugs deviennent superficiels avec suffisamment d'yeux, s'étend aux tokens. Breunig reconnaît la contrepartie : un paquet populaire est une cible plus rentable, ce qui pousse les attaquants à y investir davantage.

Le recodage garde du sens pour des fonctions simples, peu évolutives et faciles à tester, où la dépendance apporte plus de risque que de valeur. Pour du code complexe, cryptographique ou réseau, il remplace un risque partagé et surveillé par un risque isolé et invisible. Sans compter que, comme le rappelait notre précédent volet, 40 à 62 % du code généré par IA contient des vulnérabilités connues.

Le cadre réglementaire passe à l'acte

Depuis le 11 septembre 2026, le Cyber Resilience Act n'est plus un horizon. Les fabricants de produits comportant des éléments numériques doivent signaler les vulnérabilités activement exploitées et les incidents graves via la plateforme unique de signalement de l'ENISA, opérationnelle depuis cette date : alerte précoce sous 24 heures, notification sous 72 heures, puis rapport final. L'obligation vaut aussi pour les produits déjà sur le marché. Pour un éditeur dont une dépendance est piégée par un ver, la détection devient donc une question de conformité : on ne signale pas en 24 heures ce qu'on ne voit pas. Les exigences essentielles, dont la documentation des composants sous forme de SBOM, s'appliqueront à partir du 11 décembre 2027.

NIS2 impose de son côté aux entités essentielles et importantes de maîtriser les risques liés à leurs fournisseurs, logiciels compris. Quant à l'AI Act, entré en vigueur le 1er août 2024, il oblige depuis le 2 août 2025 les fournisseurs de modèles d'IA à usage général à publier un résumé de leurs données d'entraînement, premier pas vers la traçabilité que promettent les AIBOM.

Le financement suit, mais timidement. En mars 2026, Anthropic, AWS, GitHub, Google, Microsoft et OpenAI ont engagé 12,5 millions de dollars via Alpha-Omega et l'OpenSSF, notamment pour aider les mainteneurs à trier l'afflux de rapports de sécurité générés par IA. Greg Kroah-Hartman, figure du noyau Linux, a prévenu que les subventions seules ne régleraient pas le problème que ces outils posent déjà aux équipes de sécurité open source.

Recommandations

Inventorier d'abord, et en continu. Un SBOM généré à chaque build vaut mieux qu'un inventaire annuel, et il conditionne désormais la capacité à notifier dans les délais du CRA. Compléter ensuite les scans de CVE par une analyse comportementale des paquets, seule capable de repérer un ver avant qu'il ait un identifiant.

Protéger les comptes et les jetons de publication comme des secrets de production : authentification forte résistante au phishing, jetons à durée courte, publication de confiance (trusted publishing) plutôt que jetons longue durée stockés en CI. Le compte GitHub qui pilote la publication devient lui-même une cible et mérite le même niveau de protection. Désactiver les scripts d'installation quand c'est possible et imposer un délai de quarantaine avant d'adopter une nouvelle version, car les versions piégées sont souvent retirées en quelques heures.

Réserver le recodage aux fonctions simples et testables, selon des critères écrits. Pour le reste, contribuer : financer, auditer ou simplement signaler sur les projets dont on dépend reste le moyen le plus efficace de partager le coût de la sécurité.

tl;dr

Les attaques sur la chaîne d'approvisionnement logicielle sont passées à l'échelle industrielle en 2026, avec des vers comme ChainDrop capables de se republier à travers des centaines de paquets, provenance valide à l'appui. L'IA renforce la détection comportementale, seule parade face à des menaces sans CVE, mais ne remplace ni la protection des comptes de publication ni la surveillance continue. Recoder ses dépendances avec l'IA reste une option à manier avec prudence, car une bibliothèque open source partagée profite des efforts de sécurité de tous. Depuis le 11 septembre 2026, le CRA impose de signaler sous 24 heures les vulnérabilités activement exploitées, ce qui fait de la visibilité sur ses dépendances une obligation légale.

Ce volet clôt notre série consacrée à la gestion des vulnérabilités à l'ère de l'IA : la nouvelle donne, côté attaquant et côté défenseur.

Sources

Andres Freund, oss-security, mars 2024 (xz-utils, CVE-2024-3094) ; Sansec et Censys, polyfill.io, juin 2024 ; Sonatype, State of the Software Supply Chain 2024 ; Socket et StepSecurity, CanisterSprawl, avril 2026 ; Orca Security, TeamPCP et Mini Shai-Hulud, mai 2026 ; Microsoft Threat Intelligence, ChainDrop, août 2026 ; Aikido Security et Datadog Security Labs, ChainDrop, août 2026 ; Socket, levée de fonds, octobre 2024 ; Cerebro, ACM, 2025 ; TypoSmart, arXiv, février 2025 ; SLSA, Supply-chain Levels for Software Artifacts ; Drew Breunig, Cybersecurity Looks Like Proof of Work Now, avril 2026 ; Commission européenne, CRA, obligations de signalement ; ENISA, Single Reporting Platform, septembre 2026 ; Linux Foundation et OpenSSF, 12,5 M$ via Alpha-Omega, mars 2026