bodadotsh/npm-security-best-practices: How to stay safe from NPM supply chain attacks
Un ensemble de bonnes pratiques pour limiter les risques d'attaque par chaîne d'approvisionnement (supply chain attacks) avec npm.
— Permalink
Un ensemble de bonnes pratiques pour limiter les risques d'attaque par chaîne d'approvisionnement (supply chain attacks) avec npm.
Un ensemble de bonnes pratiques pour limiter les risques d'attaque par chaîne d'approvisionnement (supply chain attacks) avec npm.
Utilisateurs de npm, préparez-vous à des changements sur l’authentification et la publication.
GitHub vient de faire passer le message. Il entend réduire, « dans un avenir proche », la gamme d’options disponibles. Ne resteront plus que :
Dans ce cadre, les tokens “classiques” (legacy) seront supprimés. Il en ira de même pour le MFA à base de codes TOTP : il faudra utiliser des méthodes FIDO. Quant aux tokens granulaires, ils expireront plus vite s’ils incluent des permissions de publication.
GitHub compte aussi paramétrer la publication de sorte que les tokens ne seront pas autorisés par défaut. Objectif : encourager l’usage de la publication locale avec MFA… ou du trusted publishing. Cette fonctionnalité implémente un standard défini par l’OpenSSF. Elle utilise l’authentification OIDC pour créer une relation de confiance entre npm et les fournisseurs CI/CD (pour le moment, GitHub Actions et les pipelines GitLab, les exécuteurs autohébergés n’étant pas pris en charge). PyPi fut le premier gestionnaire de paquets à l’adopter, en 2023. RubyGems, crates.io et NuGet, entre autres, ont suivi.
Sur npm, le trusted publishing est intégré depuis juillet 2025. Il était initialement question d’en laisser se développer l’usage sans incitation particulière. Mais le contexte actuel ne le permet pas, affirme GitHub.
Ce contexte, c’est celui d’une recrudescence des attaques sur les registres de paquets logiciels. Illustration avec celle dite Shai-Hulud (du nom d’un ver des sables dans Dune). Elle a ciblé l’écosystème npm.
À l’origine, il y a possiblement une campagne de phishing ayant ciblé les développeurs, invités à “mettre à jour” leurs options de connexion MFA.
Les comptes ainsi compromis ont servi à publier un package contenant un malware. Celui-ci détectait des authentifiants dans l’environnement compromis (tokens npm et GitHub, clés d’API AWS/Azure/GCP) et les exfiltrait… tout en les rendant publics sur le compte GitHub des victimes.
Les tokens npm ainsi dérobés ont permis d’enclencher un processus de propagation automatisée du malware, ainsi apparenté à un ver. Plus de 500 packages auraient été compromis.
À l’heure actuelle, il reste possible, sur npm, de ne pas exiger le MFA pour la publication des paquets et la modification de leurs paramètres. Pour qui l’active, reste la possibilité d’autoriser les tokens, granulaires ou legacy.
Les tokens legacy (aussi dits jetons d’automatisation) permettent de télécharger des paquets et d’en publier. Ils héritent des permissions dont bénéficie l’utilisateur qui les crée.
Les tokens granulaires ont une date d’expiration et peuvent être associés à des organisations. On peut aussi les limiter à certains paquets et à des plages d’adresses IP.
Illustration générée par IA
The post Face aux compromissions, GitHub durcit la sécurité de npm appeared first on Silicon.fr.
Romain, fidèle lecteur de korben.info a développé un scanner pour détecter l’attaque Shai-Hulud qui a secoué l’écosystème npm dernièrement ! L’occasion parfaite pour moi de vous raconter cette histoire complètement dingue.
Vous vous souvenez de CrowdStrike ? Cette entreprise de cybersécurité qui a provoqué la plus grande panne informatique mondiale en juillet 2024 avec une mise à jour défaillante ? Celle qui a cloué au sol des milliers d’avions et fait planter des millions de PC Windows ? Eh bien figurez-vous qu’en septembre 2025, des packages npm mis à disposition par CrowdStrike ont été touchés. Et si Crowdstrike n’a pas été directement piraté, ces packages publics (qui n’étaient pas utilisés dans leurs solutions de sécurité, ni en interne chez eux) utilisaient ces dépendances qui ont été compromises par l’attaque.
C’est ce qu’on appelle une supply chain attack et l’attaque Shai-Hulud (oui, comme le ver des sables dans Dune) n’est pas juste un malware de plus. C’est le premier ver informatique qui s’est propagé de manière autonome dans l’écosystème npm, infectant des centaines de paquets en quelques heures.
Le ver utilise TruffleHog, un outil de sécurité normalement conçu pour DÉTECTER les secrets dans le code, c’est à dire les tokens GitHub, npm, AWS et GCP.
Puis quand il trouve des credentials valides, le ver fait les trois choses suivantes : D’abord, il crée un dépôt GitHub public nommé “Shai-Hulud” où il balance toutes les données volées. Ensuite, il pousse une GitHub Action malicieuse dans tous les repos accessibles pour exfiltrer encore plus de secrets. Et le pompon c’est que parfois, il transforme même les repos privés d’entreprise en repos publics personnels. J’vous laisse imaginer la tête du RSSI qui découvre que tout le code proprio de sa boîte est accessible à tout le monde sur GitHub…
Et quand le ver trouve des tokens npm dans son environnement, il publie automatiquement des versions infectées de tous les paquets auxquels il a accès. C’est d’ailleurs la première fois qu’on voit ce comportement de ver auto-répliquant dans l’écosystème JavaScript. Par exemple, le paquet @ctrl/tinycolor, téléchargé 2 millions de fois par semaine, a été l’un des premiers touchés.
Face à ce bordel monumental, Romain a donc développé npm-shai-hulud-scanner , un outil qui détecte non seulement les paquets connus comme compromis, mais aussi les tentatives de typosquatting et les patterns de code malicieux. Il utilise notamment la distance de Levenshtein pour identifier les variations suspectes de noms de paquets (du genre lodash vs lodash_ ou react vs raect).
Quand vous le lancez, le scanner de Romain vérifie d’abord si vous avez des paquets de la liste des 500+ compromis. Ensuite il analyse votre code à la recherche de patterns suspects : tentatives d’exfiltration de credentials, exécution de code à distance, obfuscation, communications réseau louches. Il peut même tourner en mode monitoring continu pour surveiller votre CI/CD. Et cerise sur le gâteau, il peut mettre en quarantaine les paquets suspects automatiquement. C’est top non ?
Shai-Hulud est l’un des attaques les plus sévères jamais vue sur la supply chain JavaScript et si même CrowdStrike se fait avoir, je me dit que personne n’est à l’abri. Donc soyez hyper vigilants et utilisez des outils de contrôle comme celui de Romain !
On ne sait jamais !
Quelques mesures pour éviter les supply chain attacks comme on en a vu quelques-unes dernièrement dans l'écosystème npm.
Quelques mesures pour éviter les supply chain attacks comme on en a vu quelques-unes dernièrement dans l'écosystème npm.
Des packages npm très largement utilisés (plus de 2 milliards de téléchargements par semaine au total !) ont été compromis. Pensez à vérifier si vous êtes impacté.
Des packages npm très largement utilisés (plus de 2 milliards de téléchargements par semaine au total !) ont été compromis. Pensez à vérifier si vous êtes impacté.
Une réflexion sur l'utilité relative des lockfiles, ces fichiers qui gardent trace de la version exacte de chacune des dépendances d'un projet, incluant les dépendances de dépendances, etc.
Une réflexion sur l'utilité relative des lockfiles, ces fichiers qui gardent trace de la version exacte de chacune des dépendances d'un projet, incluant les dépendances de dépendances, etc.
Ça va, pas trop chaud ? Alors tant mieux, parce que je vais vous faire avoir une petite suée tellement ce truc est cool ! Ça s’appelle Memflix et c’est une bibliothèque JavaScript qui transforme vos documents texte en… fichiers vidéo MP4 ! Oui, vous avez bien lu. Et le plus fou, c’est que vous pouvez ensuite faire des recherches sémantiques ultra-rapides dans ces vidéos.
L’idée est tellement simple qu’elle en devient géniale car au lieu de stocker vos données dans une base de données traditionnelle, Memflix encode tout dans des QR codes qui sont ensuite intégrés frame par frame dans une vidéo. Résultat ? Un stockage 10 fois plus efficace qu’une base de données classique et des recherches qui prennent moins d’une seconde, même sur des millions de chunks de texte.