NPM renforce la sécurité avec des jetons éphémères et OIDC, mais la chaîne d'approvisionnement est toujours en danger

En décembre 2025, npm a apporté un changement profond à son système d'authentification pour réduire le risque d'attaque de la chaîne d'approvisionnement : il a révoqué les soi-disant « jetons classiques » et promu les jetons de session et les flux basés sur l'OIDC. C'est une amélioration significative dans les défenses par défaut, mais il n'élimine pas complètement la possibilité d'un acteur malveillant publiant le code nuisible.

Pendant des années, la base du problème était simple : les anciennes références étaient valables depuis longtemps, avec une large gamme, et si elles tombaient dans les mauvaises mains, elles permettaient de publier de nouvelles versions de paquets sans avoir à prouver la source du code. Ce modèle a fait de npm une cible attrayante pour ceux qui cherchent à insérer des logiciels malveillants directement dans des bibliothèques très utilisées. Des incidents bien documentés dans l'écosystème ont montré à quel point les justificatifs engagés sont suffisants pour causer des dommages importants et rapides.

La réponse de npm s'est concentrée sur trois idées : une courte expiration des références interactives, une meilleure gestion des jetons et la promotion de l'utilisation d'identités liées aux exécutions par CI par l'intermédiaire de l'OIDC. Vous pouvez lire l'explication officielle de ces changements dans l'annonce d'équipe npm Voilà.. Dans la pratique, cela signifie que, pour les opérations normales, les jetons interactifs expirent rapidement et que les publications peuvent nécessiter une authentification multifactorielle.

Cependant, la sécurité réelle dépend à la fois des améliorations techniques et de la façon dont les personnes et l'équipement les utilisent. Deux points clés ouvrent toujours la porte aux attaques. Tout d'abord, les attaques d'hameçonnage visant à l'authentification multifactorielle restent efficaces : si un responsable est induit en erreur et délivre son mot de passe et un deuxième code de facteur, un attaquant peut obtenir un jeton de session valide et publier une version malveillante en quelques minutes.

Deuxièmement, la plate-forme continue de permettre des flux pensés pour l'automatisation qui, si configuré avec le contournement MFA ou des jetons à long terme (par exemple, des jetons de 90 jours), recréent essentiellement le problème précédent. Autrement dit, l'existence de jetons permanents ou de MFA omis conserve un vecteur de risque important lorsque ces secrets sont stockés ou exposés dans des systèmes CI/CD.

Ceci mène à une conclusion pratique: les améliorations de npm réduisent la fenêtre d'exposition et augmentent la difficulté pour l'attaquant, mais ne l'éliminer. Tant qu'il y aura des moyens de générer des titres de compétence persistants ou de tromper un humain pour délivrer des titres de compétence d'une seule utilisation, il y aura toujours un risque de publication non autorisé.

En termes spécifiques d'atténuation, trois axes de travail complémentaires devraient être encouragés. La première est l'adoption générale de l'ODO dans les intégrations CI; l'utilisation de jetons liés à une exécution spécifique et très courte réduit considérablement l'utilité de tout secret volé. GitHub propose une documentation sur la façon de configurer OIDC pour les déploiements qui peuvent servir de référence pratique: définir OIDC dans les actions GitHub.

La deuxième ligne est de resserrer les politiques de MFA et de minimiser les exceptions : ne pas permettre aux jetons d'éviter le facteur supplémentaire pour les opérations de publication et forcer MFA sur la console réduit la possibilité qu'un phishing soit suffisant pour publier du code. Les lignes directrices sur la prévention de l'hameçonnage et les bonnes pratiques d'authentification publiées par des organismes tels que la CISA aident à comprendre pourquoi même les utilisateurs ayant un MFA peuvent être victimes si aucun contrôle supplémentaire n'est combiné : recommandations sur l'hameçonnage (CISA).

La troisième ligne va au-delà de l'authentification : réexaminer comment les artefacts atteignent nos environnements. Si au lieu de télécharger des paquets précompilés du registre, nous reconstruisons chaque unité à partir de votre code source vérifiable, le risque qu'une version libérée avec malware atteigne nos chaînes d'approvisionnement est beaucoup réduit. Une enquête pratique menée par Chainguard soutient que, dans sa base de données publique sur les paquets commis, la plupart des cas examinés ont montré des malwares présents seulement dans le paquet publié, et non dans le code source en amont. Vous pouvez vérifier cette analyse sur le site Chainguard : Chainguard: atténuer les logiciels malveillants dans npm.

Cette approche "reconstruire à partir de la source" n'est pas banale : elle implique d'investir dans la reproductibilité, la signature d'objets et de chaînes de confiance, mais a un effet tangible sur la réduction de la surface de l'attaque. Les outils et les services qui fournissent des bibliothèques construites vérifiables peuvent s'intégrer à un modèle de défense approfondi qui combine des politiques d'accès strictes, des vérifications et des vérifications en temps de mise en oeuvre.

Finalement, ce qui attire l'attention, c'est qu'il n'y a pas de solution miraculeuse unique. La sécurité efficace est une somme de couches: bonne pratique dans la gestion des références, utilisation généralisée de l'OIDC pour l'automatisation, MFA obligatoire dans les actions sensibles et, si possible, la reconstruction vérifiée des appareils à partir de la source. Chaque mesure réduit le risque restant laissé par les autres.

Pour les projets et les organisations, cela se traduit par des décisions concrètes : examiner et faire pivoter les jetons, permettre à MFA et supprimer les exceptions de contournement, migrer les pipelines vers l'OIDC lorsque cela est possible, et envisager l'adoption de dépôts ou de services qui garantissent que ce qui est installé provient du code source vérifié. Les recommandations pratiques et les guides d'outils publics - comme ceux de GitHub pour l'OIDC ou l'analyse d'incidents des fournisseurs de sécurité - sont des ressources utiles pour planifier cette transition.

npm a évolué dans la bonne direction en modifiant les politiques par défaut et en éliminant les pouvoirs péremptoires. Pourtant, tant que des vecteurs humains (phishing) existent et que la possibilité de générer des jetons à long terme, la menace sur la chaîne d'approvisionnement reste. La chose la plus raisonnable pour la communauté est de combiner les améliorations de la plate-forme avec les changements de processus et l'adoption de technologies qui élèvent la barrière pour un attaquant au point que l'exploitation du système ne sera plus rentable.

Si vous souhaitez approfondir le contexte et les cas spécifiques de la façon dont les justificatifs d'identité ont été utilisés dans le passé, Snyk propose une analyse informative de l'incident « event-stream », un des exemples les plus cités de l'attaque de la chaîne d'approvisionnement JavaScript: analyse de l'incident-stream (Snyk). Et si vous êtes intéressé à explorer des alternatives techniques axées sur la construction d'objets à partir de la source, la documentation de Chainguard sur ses bibliothèques JavaScript explique cette approche avec des exemples et des données.

En conclusion, il convient de rappeler que cet article est basé sur les travaux et l'analyse de la communauté technique. Les recommandations ne visent pas à alarmer, mais plutôt à mettre en perspective que les améliorations de npm réduisent les risques mais ne disparaissent pas, et que la réponse la plus efficace est de combiner les contrôles techniques avec l'hygiène opérationnelle et la vérification des sources.