Chaque compromission dans la chaîne d'approvisionnement a un moment où la confiance change discrètement de mains. Le nôtre s'est produit dans un système que presque aucune équipe ne regarde : le lien entre un dépôt GitHub et un paquet npm.
Les chercheurs de Bloom Security ont baptisé la faille SlugFest, et la métaphore de leur chercheur principal Golan Myers est celle qui est restée : c'est comme une serrure qui vérifie l'adresse sur la porte plutôt que le propriétaire de la maison. Quand le propriétaire déménage, celui qui emménage récupère la clé.
Voici la partie inconfortable. Personne n'a eu besoin de voler un identifiant. La seule condition préalable était de renommer un dépôt.
Ce que la publication de confiance npm devait résoudre
En juillet 2025, npm a lancé la publication de confiance (trusted publishing), et l'idée était vraiment bonne. Au lieu de stocker des jetons npm de longue durée sur un serveur de build (et de les laisser fuiter dans les journaux, les caches et les runners CI compromis), un workflow GitHub Actions demande un jeton OpenID Connect éphémère, le présente à npm et reçoit en échange un identifiant de publication. Les versions arrivent avec des attestations de provenance, ce qui permet à quiconque de retracer où un paquet a été construit.
Le design élimine toute une classe d'incidents de fuite de secrets. Il a aussi introduit un mode de défaillance subtil, à cause d'un seul champ.
npm a lié la relation de confiance à l'adresse lisible du dépôt : owner/repository. Les jetons OIDC de GitHub transportent aussi l'ID numérique permanent du dépôt, qui survit aux renommages et aux transferts. npm, jusqu'à la première publication réussie d'un paquet, ignorait totalement ce numéro et se contentait de comparer le nom.
Les noms bougent. Ils se libèrent quand un mainteneur renomme, transfère ou supprime un dépôt, et une fois qu'un nom est libre, n'importe qui peut le revendiquer.
Comment SlugFest fonctionne réellement
- Un mainteneur configure la publication de confiance pour un paquet, mais n'a pas encore publié de version depuis ce dépôt : la liaison repose donc encore sur le nom.
- Le mainteneur renomme, transfère ou supprime le dépôt. L'ancien slug
owner/repositorydevient disponible. - Un attaquant crée un dépôt exactement à cet emplacement libéré et déclenche un workflow de publication. GitHub émet un jeton OIDC portant le nom revendiqué et un tout nouvel ID de dépôt.
- npm vérifie le nom, constate qu'il correspond à la configuration stockée et délivre un jeton de publication pour un paquet qui n'appartient pas à l'attaquant.
À partir de là, l'attaquant publie une version malveillante sous le nom légitime du paquet. Les compteurs de téléchargements, la réputation et tous les projets dépendants suivent. Le scan de Bloom sur l'ensemble du registre a identifié plus de 1 500 paquets vulnérables, totalisant plus de 10 millions de téléchargements cumulés et plus d'un million de téléchargements par mois.
Bloom a signalé la faille à GitHub le 6 juin 2026. Elle a été qualifiée le 9 juin. Puis la piste s'est refroidie en juillet, et le correctif n'est arrivé que lorsque les chercheurs se préparaient à publier, plus de 120 jours plus tard. GitHub et npm ont depuis confirmé la remédiation et présenté leurs excuses pour cette communication tardive.
Le correctif a exactement la bonne forme : les configurations de publication de confiance nouvellement créées expirent désormais après 48 heures si elles ne réalisent pas une première publication réussie, qui valide la liaison à l'identité immuable du dépôt. Modifier l'identité d'un dépôt ou d'un projet exige une nouvelle relation de confiance et une nouvelle fenêtre de 48 heures. npm a également cessé d'accepter les jetons de publication de confiance issus d'événements issue_comment, en plus de la restriction existante sur pull_request_target.
Puis les agents sont arrivés
Si SlugFest ne concernait que des développeurs humains lançant npm install, ce serait déjà sérieux. C'est la seconde moitié de la recherche de Bloom qui devrait changer votre façon de voir votre pipeline de build.
Bloom a étudié des millions d'agents IA dans des dizaines d'organisations. Le poste moyen reçoit environ 70 paquets installés par des agents IA chaque mois. Les machines de développement approchent 350. Chaque agent installe entre 0,3 et 1,2 paquet par jour ; sur les machines de développement, les installations directes vont de deux à trois par jour, en plus de tout ce que ces paquets entraînent. Un poste typique exécute trois agents, entre lignes de commande, IDE, extensions et assistants. Les machines de développement en exécutent cinq ou plus.
Alignez maintenant cela avec le comportement d'un agent. Il résout lui-même les dépendances, préfère la dernière version et demande rarement d'où vient un paquet. Une version malveillante publiée via un slug récupéré est installée, et son hook postinstall s'exécute sans aucun humain dans la boucle.
Bloom l'a constaté en production, en bloquant l'agent IA d'un client qui tentait d'installer l'un des paquets concernés.
Le bénéfice pour l'attaquant est une cascade. Compromettez un paquet. Un agent IA sur la machine d'un mainteneur populaire le tire. Ce poste devient la rampe de lancement d'une version malveillante du paquet du mainteneur lui-même, et tous ses consommateurs sont exposés. C'est le schéma Shai-Hulud, avec un accélérateur.
La provenance n'est pas une case à cocher
Il existe un second angle mort qui mérite attention, car c'est le genre de chose qui survit à un audit de conformité.
Une version malveillante peut porter une attestation de provenance générée par le dépôt de l'attaquant lui-même. Certains systèmes de vérification contrôlent seulement qu'une attestation existe, pas que sa source correspond au mainteneur dont le paquet était censé venir. La signature est réelle. Le signataire est le mauvais. C'est ici que le contrôle de la chaîne d'approvisionnement doit passer de « est-ce signé ? » à « est-ce signé par l'identité à laquelle je fais confiance, et cette identité est-elle encore le même objet qu'au mois dernier ? ».
À noter que le Warehouse de PyPI stocke déjà des identifiants immuables, ce que Bloom recommandait pour npm. La voie GitLab de la publication de confiance npm présentait la même faiblesse.
Ce que cela signifie pour les clients d'aratech
La plupart des organisations ne peuvent pas corriger un registre et ne vont pas cesser d'utiliser npm. Ce qu'elles peuvent faire, c'est arrêter de traiter l'arrivée des paquets comme un événement invisible.
- Auditez dès aujourd'hui les liaisons de publication de confiance. Les mainteneurs disposant de droits de publication doivent exécuter
npm trust listet vérifier que chaque slug configuré pointe toujours vers un dépôt qu'ils contrôlent. Toute liaison pointant vers un dépôt renommé, transféré ou supprimé doit être supprimée et recréée. - Traitez l'hygiène des dépôts comme du travail de sécurité. Supprimer une liaison de confiance à chaque renommage, transfert ou suppression de dépôt doit être une étape écrite du runbook, pas une bonne intention.
- Placez une barrière devant le chemin d'installation. Un pare-feu de chaîne d'approvisionnement qui décide ce qui entre dans l'environnement est le contrôle qui passe réellement à l'échelle, parce qu'il ne dépend pas d'un humain relisant un diff de lockfile à 18 h.
- Étendez l'inventaire au-delà des paquets. Auditez les extensions, plugins, serveurs MCP, skills et applications. Bloom a trouvé le même schéma en août dans Open VSX et le Marketplace VS Code : 87 packs d'extensions dans l'un et 677 dans l'autre référençaient des extensions inexistantes, libres à revendiquer.
- Écrivez la politique des agents. Quels agents peuvent installer des logiciels, depuis quels registres, avec quelle approbation, et comment vous le sauriez après coup.
Le schéma à retenir
Deux ans d'actualités de sécurité liées à l'IA tournent autour de la même leçon, et SlugFest l'énonce proprement : la liaison entre un nom lisible et la chose qu'il identifie est l'invariant le plus important de tout système de confiance. Cassez-le par un simple renommage et la garantie s'effondre, silencieusement, sans alerte et sans la moindre connexion échouée.
Vos agents sont désormais de l'infrastructure. Ils installent du code à la vitesse de la machine, dans des environnements dont vous êtes responsable. Le nom sur la porte n'est plus une preuve de qui se trouve à l'intérieur. Vérifiez l'identité, pas l'orthographe, et faites-le automatiquement.