Une augmentation spectaculaire des intrusions axées sur le NPM montre comment les attaquants sont passés du typosquatting opportuniste à des compromissions systématiques de la chaîne d’approvisionnement basées sur les informations d’identification, en exploitant les systèmes CI, les responsables et les profondes faiblesses des pipelines DevOps modernes.
Une augmentation massive des attaques contre l’écosystème NPM au cours de l’année écoulée révèle un changement radical dans le paysage des menaces liées à la chaîne d’approvisionnement logicielle.
Ce qui équivalait autrefois à des tentatives bâclées de typosquatting a évolué vers des intrusions coordonnées et basées sur des informations d’identification ciblant les responsables, les pipelines CI et l’automatisation fiable qui sous-tend le développement moderne.
Pour les responsables de la sécurité, il ne s’agit plus d’incidents de développement de niche : il s’agit d’une voie directe vers les systèmes de production, l’infrastructure cloud et des millions d’applications en aval.
Le but n’est plus de tromper un développeur individuel, mais d’hériter tranquillement de son autorité. Et avec cela, leur portée de distribution.
« NPM est une cible intéressante car il s’agit du plus grand référentiel de packages JavaScript au monde et d’un point de contrôle clé pour la distribution de logiciels », a déclaré Melinda Marks, directrice des pratiques de cybersécurité chez Enterprise Security Group. « Les équipes de sécurité doivent comprendre les dépendances et les moyens d’auditer et d’atténuer régulièrement les risques. »
Faiblesses structurelles de l’infrastructure NPM
Presque toutes les entreprises s’appuient sur NPM, que ce soit directement ou indirectement. Selon IDC, 93 % des organisations utilisent des logiciels open source et npm reste le plus grand registre de packages de l’écosystème JavaScript. « La compromission d’un seul package populaire peut immédiatement atteindre des millions d’utilisateurs et d’applications en aval », a déclaré Katie Norton, responsable de la recherche (DevSecOps) d’IDC, transformant un identifiant volé en ce qu’elle a décrit comme une « clé principale » pour la distribution.
Cette ampleur ne représente toutefois qu’une partie du risque.
L’exposition est amplifiée par les faiblesses structurelles dans la manière dont les pipelines de développement modernes sont sécurisés, a fait remarquer Norton. « Les responsables individuels du logiciel open source ne disposent souvent pas des ressources de sécurité sur lesquelles s’appuient les équipes de l’entreprise, ce qui les rend vulnérables à l’ingénierie sociale », a-t-elle déclaré. « Les exécuteurs CI/CD et les machines de développement traitent régulièrement les secrets de longue durée qui sont stockés dans des variables d’environnement ou des fichiers de configuration et sont facilement exploités par des logiciels malveillants. »
« Les systèmes de construction ont également tendance à donner la priorité à la vitesse et à la fiabilité plutôt qu’à la visibilité sur la sécurité, ce qui entraîne une surveillance limitée et de longs temps d’arrêt pour les attaquants qui obtiennent un accès initial », a ajouté Norton.
Même si les responsables de la sécurité ne peuvent pas s’en sortir, ils peuvent réduire l’exposition. Les experts soulignent systématiquement les mêmes priorités : traiter les exécuteurs CI comme des actifs de production, faire tourner et définir la portée des jetons de publication de manière agressive, désactiver les scripts de cycle de vie sauf si nécessaire et épingler les dépendances sur des versions immuables.
« Ces attaques NPM ciblent la phase de pré-installation des dépendances logicielles, de sorte que les méthodes typiques de sécurité de la chaîne d’approvisionnement logicielle en matière d’analyse de code ne peuvent pas répondre à ces types d’attaques », a déclaré Marks. La détection nécessite une analyse d’exécution et une détection des anomalies plutôt que des outils basés sur les signatures.
Des pièges à fautes de frappe aux portes dérobées légitimes
Pendant des années, le typosquatting a défini le modèle de menace du NPM. Les attaquants ont publié des packages dont les noms étaient juste assez proches de ceux des bibliothèques populaires, tels que « lodsash », « expres », « reacts » et ont attendu que l’automatisation ou une erreur humaine fasse le reste. L’impact était généralement limité et les mesures correctives simples.
Ce modèle a commencé à s’effondrer en 2025.
Au lieu de se faire passer pour des packages populaires, les attaquants compromettaient de plus en plus les packages réels. Les campagnes de phishing usurpant npm lui-même ont permis de récolter les informations d’identification du responsable. Les jetons volés ont ensuite été utilisés pour publier des mises à jour de chevaux de Troie qui semblaient légitimes à chaque consommateur en aval. La campagne Shai-Hulud a illustré l’ampleur du problème, affectant des dizaines de milliers de référentiels et exploitant les informations d’identification compromises pour se propager à travers l’écosystème.
« L’écosystème NPM est devenu le joyau du développement moderne », a déclaré Kush Pandya, chercheur en cybersécurité chez Socket.dev. « Lorsqu’un seul mainteneur prolifique est compromis, le rayon d’explosion s’étend sur des centaines de projets en aval. »
Le résultat a été un changement discret mais puissant : les attaquants n’ont plus besoin de créer des contrefaçons convaincantes. Ils pourraient diffuser des logiciels malveillants via des canaux fiables, signés et versionnés comme n’importe quelle mise à jour de routine.
Environnements de développement sur ordinateurs portables de développeur
Les attaques npm modernes s’activent de plus en plus dans les environnements CI/CD plutôt que sur les ordinateurs portables des développeurs. Les scripts de post-installation, longtemps traités comme des aides à la configuration inoffensives, sont devenus un vecteur d’exécution capable de s’exécuter automatiquement dans GitHub Actions ou GitLab CI. Une fois à l’intérieur d’un exécuteur, les packages malveillants pourraient lire des variables d’environnement, voler des jetons de publication, falsifier des artefacts de construction ou même diffuser des versions malveillantes supplémentaires sous l’identité de la victime.
« Les environnements de développement et les exécuteurs CI valent désormais plus que les machines des utilisateurs finaux », a noté Pandya. « Ils disposent généralement d’autorisations plus larges, d’un accès aux secrets et de la possibilité de mettre du code en production. »
Plusieurs campagnes observées à la mi-2025 étaient explicitement compatibles CI, se déclenchant uniquement lorsqu’elles détectaient des environnements de construction automatisés. Certaines incluaient une exécution retardée ou des charges utiles à expiration automatique, minimisant la visibilité médico-légale tout en maximisant le vol d’informations d’identification.
Pour les entreprises, cela représente un changement de risque fondamental. Les systèmes CI fonctionnent souvent avec des privilèges plus élevés que n’importe quel utilisateur individuel, mais sont surveillés de manière beaucoup moins rigoureuse. « Ils sont souvent sécurisés avec des valeurs par défaut plus faibles : jetons de publication de longue durée, secrets CI trop permissifs, confiance implicite dans les scripts de cycle de vie et les métadonnées des packages, et peu d’isolation entre les builds », a noté Pandya.
Selon IDC Research, les organisations allouent seulement environ 14 % de leurs budgets AppSec à la sécurité de la chaîne d’approvisionnement, et seulement 12 % d’entre elles identifient la sécurité des pipelines CI/CD comme un risque majeur.
L’évasion comme fonctionnalité de première classe
À mesure que les défenseurs ont amélioré leur capacité à repérer les colis suspects, les attaquants se sont également adaptés.
Les campagnes NPM récentes ont utilisé des caractères Unicode invisibles pour masquer les dépendances, des chargeurs à plusieurs étapes qui récupèrent les charges utiles réelles uniquement après des vérifications de l’environnement et des références de commande et de contrôle (C2) hébergées par la blockchain conçues pour échapper aux retraits. D’autres ont déployé un comportement semblable à celui d’un ver, utilisant des informations d’identification volées pour publier des packages malveillants supplémentaires à grande échelle.
L’examen manuel est devenu largement inefficace contre ce niveau de métier. « L’époque où vous pouviez parcourir index.js et repérer un eval() malveillant est révolue », a déclaré Pandya.
« Les packages modernes cachent une logique malveillante derrière des couches d’encodage, d’exécution retardée et d’empreintes digitales de l’environnement. » Norton a fait écho à cette préoccupation, soulignant que ces attaques opèrent à un niveau comportemental où l’analyse statique est insuffisante. « Les techniques d’obscurcissement rendent difficile la distinction entre la logique malveillante et la complexité légitime dans les grands projets JavaScript », a-t-elle déclaré. « Les charges utiles compatibles CI et les scripts de post-installation introduisent un comportement qui ne se manifeste que dans des conditions environnementales spécifiques. »
