Réponse rapide: Les attaques de la chaîne d'approvisionnement Npm fonctionnent en compromettant un compte de mainteneur de confiance ou un CI/CD Ce procédé consiste à utiliser un jeton, à publier une version malveillante d'un paquet auquel les développeurs font déjà confiance, puis à laisser les scripts d'installation ou la logique du ver de ce paquet faire le reste. Entre août 2025 et mi-2026, ce schéma a engendré la plus importante vague d'attaques contre la chaîne d'approvisionnement des paquets npm de l'histoire du registre, notamment le détournement de chalk/debug. Ver Shai-Huludet des logiciels malveillants d'État dissimulés dans un paquet téléchargé 100 millions de fois par semaine. La solution ne consiste pas à analyser le code après son installation, mais à intercepter les paquets malveillants avant leur installation et à surveiller… pipeline pour le comportement précis que ces attaques partagent.
Chaque installation est un acte de confiance, et les attaquants le savent.
Un développeur exécute npm installerDerrière cette simple commande se cache une arborescence de dépendances comprenant des centaines, voire des milliers, de paquets, la plupart écrits et maintenus par des personnes que le développeur ne rencontrera jamais. Personne n'examine cette arborescence ligne par ligne. Personne n'en a le temps.
Cette confiance est la cible. Il est moins coûteux pour un attaquant d'hameçonner un mainteneur npm avec 2.6 milliards de téléchargements hebdomadaires que de trouver une faille zero-day dans le pare-feu d'une entreprise du Fortune 500. Les attaques contre la chaîne d'approvisionnement npm exploitent précisément cette asymétrie, et la vague de 2025-2026 montre à quel point cette exploitation s'est propagée : de typosquatting isolé aux vers auto-reproducteurs qui publient leurs propres logiciels malveillants plus rapidement que n'importe quel humain ne peut réagir.
Qu’est-ce qui constitue une attaque de la chaîne d’approvisionnement npm ?
Une attaque de la chaîne d'approvisionnement npm est tout incident au cours duquel un attaquant insère du code malveillant dans la distribution npm. pipeline plutôt que de s'infiltrer dans le code source de la cible, le logiciel malveillant arrive déguisé en mise à jour de dépendance de routine. Le point d'entrée est généralement l'un des trois suivants : les identifiants volés d'un mainteneur, un compte de publication volé ou CI/CD jeton, ou une version compromise pipeline qui est ainsi amené à publier du code au nom de l'attaquant. Étant donné que les paquets npm incluent automatiquement les dépendances transitives, un seul paquet compromis peut affecter des applications qui ne l'ont jamais déclaré comme dépendance directe.
Chronologie : les plus grandes attaques contre la chaîne d'approvisionnement npm de 2025-2026
Le schéma sous-jacent à chaque attaque de la chaîne d'approvisionnement des packages npm
Si l'on fait abstraction des détails, presque tous les incidents décrits ci-dessus suivent les mêmes quatre étapes :
- Compromettre une identité, pas un système. Un responsable de compte victime d'hameçonnage, un jeton npm divulgué, un jeton d'accès personnel GitHub volé ou un jeton OIDC extrait de CI/CD Mémoire du programme d'exécution. L'attaquant ne corrompt pas le registre. Il emprunte la clé d'accès à celui-ci.
- Publiez sous un nom auquel les développeurs font déjà confiance. Il n'est pas nécessaire de recourir au typosquatting lorsque le nom réel du paquet fonctionne. C'est ce qui rend ces attaques si efficaces contre les mises à jour automatiques. pipelines : la mise à jour semble tout à fait légitime.
- Fuyez avant que quelqu'un ne le commente. Les scripts d'installation malveillants, les charges utiles obfusquées ou le code dormant qui ne s'active que sous certaines conditions s'exécutent dès que possible. npm installer Ces programmes s'exécutent, souvent sur l'ordinateur portable d'un développeur, bien avant qu'une analyse de sécurité planifiée ne les détecte.
- Persister et, de plus en plus, se propager. Shai-Hulud et ses descendants utilisent les identifiants qu'ils volent pour publier automatiquement le prochain paquet infecté, transformant une simple compromission en une réaction en chaîne à travers le graphe de dépendances.
Pourquoi les défenses habituelles échouent-elles ?
La plupart des outils de sécurité applicative ont été conçus pour analyser le contenu du dépôt : vulnérabilités connues (CVE), modèles de code statiques, problèmes de licence. Bien que nécessaire, cette analyse arrive structurellement trop tard pour ce type d’attaque. Lorsqu’un scanner détecte une dépendance, le script d’installation a peut-être déjà été exécuté sur la machine du développeur. Les antivirus et EDR traditionnels surveillent le système d’exploitation, et non les registres de paquets ; ils n’ont donc aucune notion d’une « nouvelle version npm » comme unité de risque. Et comme le montrent les incidents TanStack et Red Hat, même les attestations d’intégrité de la compilation, telles que… SLSA provenance Cela ne sert à rien si l'attaquant a légitimement capturé l'identité qui les signe : la signature est valide, mais le paquet reste malveillant.
La faille exploitée par ces attaques sur la chaîne d'approvisionnement npm se situe précisément au moment de la publication et de l'installation, avant qu'une signature du logiciel malveillant n'existe et avant que le paquet n'ait été exécuté à un endroit où un scanner traditionnel pourrait effectuer une analyse.
Comment stopper la prochaine attaque contre la chaîne d'approvisionnement de npm
Une partie de cela relève de la discipline de processus que chaque équipe d'ingénierie peut adopter dès aujourd'hui :
- Dépendances des broches et commit fichiers de verrouillage, de sorte qu'une mise à jour automatique ne peut pas intégrer silencieusement une version malveillante qui vient d'être publiée.
- Désactiver ou mettre en quarantaine les scripts post-installation Par défaut, la plupart des paquets n'ont pas besoin d'exécuter de code arbitraire lors de l'installation.
- Imposer une authentification multifacteur matérielle pour les comptes de publication npm, fermant ainsi la faille exacte dans la faille de sécurité qui a compromis les comptes de chalk, debug et Qix.
- Portée et rotation CI/CD jetons de manière agressiveet traitez les jetons OIDC dans la mémoire du runner comme une information d'identification à protéger, et non comme un détail d'implémentation.
- Observez le schéma déverrouillage-injection-reverrouillage in CI/CD: une règle de protection de branche désactivée, un commit La règle a été réactivée, puis poussée, le tout dans un laps de temps très court. C'est une caractéristique récurrente de pipeline-compromis au niveau de la chaîne d'approvisionnement.
Là où la discipline des processus s'épuise
La rigueur des processus réduit l'exposition aux menaces. Elle ne permet pas de détecter un logiciel malveillant dès sa publication, ni un ver informatique qui se propage déjà à une vitesse fulgurante, trop rapide pour être analysé par un humain. C'est précisément le niveau de sécurité que la solution de sécurité de la chaîne d'approvisionnement de Xygeni prend en charge.
Xygéni MEW (Alerte précoce aux logiciels malveillants) Il analyse en continu les nouveaux paquets publiés sur npm, PyPI et Maven, détectant les logiciels malveillants avant même l'existence d'une signature, et réinjectant les menaces confirmées dans le système. Xygéni son propre moteur de détection. Pare-feu de dépendance Il analyse en temps réel les paquets npm, PyPI, Maven, NuGet et RubyGems et bloque les installations malveillantes avant qu'elles n'atteignent la machine d'un développeur ou une compilation. CI/CD Détection d'une anomalie montres pipelines pour comprendre précisément le schéma comportemental à l'origine d'incidents comme la compromission de TanStack, y compris la séquence de déverrouillage-injection-reverrouillage, avec une piste d'audit complète. Et parce que Xygeni Triage et remédiation basés sur l'IA Cela s'applique également aux résultats des scanners tiers ; les équipes n'ont pas besoin de remplacer leurs outils existants pour combler cette lacune.
FAQ : Attaques de la chaîne d’approvisionnement npm
Qu'est-ce qu'une attaque de la chaîne d'approvisionnement npm ?
Il s'agit d'une attaque où du code malveillant atteint une application cible via une dépendance npm de confiance plutôt que par le code propre de la cible, généralement parce qu'un attaquant a compromis le compte d'un mainteneur, un jeton de publication ou un CI/CD pipelinel'identité de.
Quelle a été la plus importante attaque contre la chaîne d'approvisionnement de npm ?
Par son ampleur, le détournement de chalk/debug en septembre 2025 figure parmi les plus importants : 18 paquets, totalisant 2.6 milliards de téléchargements hebdomadaires, ont été compromis via un seul compte de mainteneur piraté. Sur le plan technique, Shai-Hulud a constitué un tournant majeur, puisqu'il s'agissait du premier ver à propagation automatique de l'histoire de npm.
Comment se déroule généralement une attaque sur la chaîne d'approvisionnement des paquets npm ?
Presque toujours avec une identité volée : un responsable de maintenance victime d’hameçonnage, un jeton de publication divulgué ou un compte volé. CI/CD une identification telle qu'un jeton OIDC extrait de la mémoire d'un exécuteur, plutôt qu'une intrusion technique dans npm lui-même.
Un antivirus ou un EDR peut-il stopper une attaque de la chaîne d'approvisionnement npm ?
De manière non fiable. Les solutions EDR surveillent le système d'exploitation mais ne prennent pas en charge les registres de paquets, et les antivirus, basés sur la signature, sont inefficaces contre les logiciels malveillants publiés avant l'existence de toute signature. Pour contrer ce type d'attaque, une surveillance est nécessaire dès la publication et l'installation, et non uniquement au niveau du terminal.
Le SLSA provenance ou créer une attestation pour empêcher cela ?
Cela prouve que pipeline Le fichier lui-même n'a pas été altéré lors de la compilation. Cela ne prouve pas pour autant que l'identité ayant déclenché la compilation n'ait pas été compromise, comme l'ont démontré les incidents TanStack et Red Hat, qui comportaient des attestations valides associées à des paquets malveillants.
Comment une équipe peut-elle détecter un package npm malveillant avant son installation ?
En exécutant une analyse continue des logiciels malveillants avant leur signature sur les nouveaux packages publiés, ce que font un système d'alerte précoce aux logiciels malveillants et un pare-feu de dépendances, plutôt que de s'appuyer uniquement sur une analyse de vulnérabilité a posteriori du code déjà présent dans un dépôt.
Par où commencer
Les attaques ciblant la chaîne d'approvisionnement de npm ne faiblissent pas, et la tendance observée depuis Shai-Hulud indique une automatisation accrue, et non l'inverse. Les équipes les mieux placées pour la prochaine campagne sont celles qui ont cessé de considérer chaque installation npm comme une opération de routine et qui ont commencé à surveiller le registre. pipelineet le point de terminaison comme une surface d'attaque connectée.
Le plan Développeur de Xygeni inclut la couverture MEW et le pare-feu de dépendances Vous pouvez l'utiliser gratuitement pour un maximum de 25 dépôts. C'est un outil pratique pour visualiser les dépendances existantes.
