Synthèse sur les attaques des dépôts Node Package Manager (NPM)

Je vous propose une synthèse sur les deux dernières attaques sur les dépôts NPM.

Le maillon faible de la chaîne numérique

Dans le paysage du développement logiciel contemporain, où la rapidité et la réutilisation du code sont primordiales, le gestionnaire de paquets Node Package Manager (NPM) est devenu un pilier indispensable de l’écosystème JavaScript. Agissant comme le plus grand référentiel de bibliothèques open-source au monde, avec plus de 3 millions de paquets et des milliards de téléchargements hebdomadaires, NPM simplifie la gestion des dépendances et accélère considérablement le cycle de vie du développement.¹ Il permet aux développeurs de s’appuyer sur des composants préexistants pour construire des applications complexes, des sites web aux outils de développement.² C’est cette ubiquité et cette interconnexion qui, paradoxalement, transforment le dépôt en une cible de choix pour les cybercriminels, dont l’exploitation peut entraîner des répercussions exponentielles.

L’escalade des menaces sur NPM s’inscrit dans un contexte plus large d’attaques de la chaîne d’approvisionnement logicielle. Contrairement à une attaque directe sur une entreprise, ce type de menace cible un fournisseur ou un maillon de la chaîne de production – dans ce cas, le référentiel de code – pour infiltrer indirectement un grand nombre de clients en aval.³ Cette approche stratégique permet aux attaquants de contourner les défenses périmétriques traditionnelles et d’optimiser leur effort pour un effet de cascade maximal.⁵

Les données récentes confirment la gravité de cette tendance, avec une augmentation notable de la fréquence et de la sophistication des attaques.⁶ Les prévisions estiment les dommages annuels liés à ces attaques à 138 milliards de dollars d’ici 2031, soulignant leur impact économique systémique.⁶ La forte dépendance aux composants open-source et l’automatisation croissante des pipelines d’intégration continue et de déploiement continu (CI/CD) ont créé un terrain fertile pour la propagation de maliciels à grande échelle, transformant le dépôt NPM en un vecteur de diffusion de masse.⁸

L’année 2025 marque un tournant significatif dans cette menace, illustré par deux incidents majeurs survenus coup sur coup en septembre. Ces événements ne sont pas de simples occurrences isolées, mais le reflet d’une menace professionnelle et diversifiée, exploitant non seulement les failles techniques, mais aussi les vulnérabilités humaines et les processus de l’écosystème. Le premier incident, surnommé l’attaque debug/chalk, a révélé l’efficacité de l’ingénierie sociale ciblée.

Une campagne d’hameçonnage sophistiquée a ciblé les mainteneurs de paquets en leur envoyant de faux courriels d’assistance de NPM, leur demandant de « mettre à jour » leur authentification à deux facteurs (2FA) sur un faux domaine npmjs.help.¹⁰ Malgré l’activation de la 2FA par les mainteneurs, l’attaque a réussi à dérober les identifiants et le code TOTP, permettant aux pirates de prendre le contrôle des comptes.⁹ Ils ont ensuite injecté un code malveillant dans 18 paquets populaires, dont les bibliothèques

debug et chalk, qui totalisent des milliards de téléchargements hebdomadaires.¹⁰ La charge utile de ce maliciel opérait exclusivement dans les environnements de navigateur, interceptant les API web pour les transactions de cryptomonnaies.⁹ Son mécanisme sophistiqué utilisait un algorithme de Levenshtein, une mesure de similarité de chaînes de caractères, pour remplacer les adresses de portefeuille de la victime par des adresses contrôlées par l’attaquant, qui étaient visuellement indiscernables pour un utilisateur non averti.¹⁰

Peu de temps après, un second incident a secoué la communauté. L’apparition d’un ver auto-réplicatif, baptisé « Shai-Hulud », a marqué une nouvelle phase d’escalade. Cette menace, décrite comme une évolution de précédentes attaques, ne se contentait pas d’une seule injection de code. Elle a dérobé des jetons d’authentification pour les dépôts NPM et GitHub, ainsi que des clés d’accès aux services cloud (AWS, GCP).¹⁴ Une fois ces informations en main, le ver s’est propagé de manière autonome, injectant son propre code malveillant dans d’autres paquets maintenus par la victime et publiant de nouvelles versions corrompues dans le dépôt.¹⁴

La prolifération a été exponentielle, affectant plus de 180 paquets au moment de sa détection initiale, un nombre qui a depuis dépassé les 500.¹⁵ Le modus operandi de ce ver est particulièrement alarmant, car il n’utilisait pas de serveurs de commande et de contrôle traditionnels pour l’exfiltration des données. Au lieu de cela, il a publié les secrets volés sur des dépôts publics sur GitHub, en créant de nouvelles copies de dépôts privés avec un suffixe -migration.¹⁴

De plus, les chercheurs ont observé que la conception du ver incluait l’utilisation d’outils open-source légitimes comme trufflehog pour la recherche de secrets sur les systèmes, et ont évalué avec une confiance modérée que l’intelligence artificielle a été utilisée pour la génération de son script malveillant, ce qui signale une accélération de la sophistication des menaces.¹⁴

L’analyse de ces deux événements simultanés révèle une réalité à multiples facettes de la menace sur la chaîne d’approvisionnement logicielle. L’attaque debug/chalk met en lumière l’importance croissante du facteur humain comme le principal point d’entrée, où l’ingénierie sociale parvient à contourner des protections techniques sophistiquées comme la 2FA.⁹

D’autre part, l’émergence du ver Shai-Hulud indique une évolution des menaces vers l’autonomie et la prolifération. Ce type d’attaque transforme la compromission d’un seul individu en une menace systémique capable de s’auto-entretenir et de se propager sans l’intervention continue de l’attaquant, exploitant les privilèges de publication existants d’un mainteneur.¹⁵ En somme, ces incidents démontrent que la menace n’est plus statique ; elle apprend, s’adapte et exploite l’automatisation, la confiance implicite et les faiblesses humaines.

Cette évolution souligne l’urgence pour l’ensemble de l’écosystème de repenser la sécurité au-delà des mesures périmétriques traditionnelles, en reconnaissant que la chaîne d’approvisionnement du code est aussi vulnérable que son maillon le plus faible.

Partie I. Anatomie des attaques de la chaîne d’approvisionnement logicielle sur NPM

A. Le rôle critique de Node.js et de son écosystème de paquets

Le gestionnaire de paquets NPM est indissociable de l’environnement d’exécution Node.js, agissant comme l’épine dorsale du développement web moderne.¹ Son rôle s’étend au-delà de la simple gestion de bibliothèques ; il est le point central de la collaboration et de la réutilisation du code, permettant aux développeurs d’accéder à des millions de paquets pour accélérer leurs projets.² Cette efficacité repose sur un modèle d’interdépendance où un paquet peut en appeler un autre, créant un arbre de dépendances complexe et souvent imbriqué.¹⁰ Un paquet relativement simple et largement utilisé, comme chalk ou debug, peut être une dépendance « transitive », c’est-à-dire une dépendance d’une dépendance, pour des milliers d’applications.⁸ Cette structure interconnectée crée un effet de cascade, où la compromission d’un seul maillon, aussi petit soit-il, peut se propager silencieusement à des centaines de projets et d’organisations en aval, transformant une attaque ciblée en une menace généralisée.⁸

B. Les vecteurs d’attaque : une typologie détaillée

Les attaques sur les dépôts NPM ne se limitent pas à un seul modus operandi. Elles exploitent une variété de techniques, allant de la manipulation humaine à l’exploitation des failles de configuration.

1. La compromission de comptes par ingénierie sociale (Phishing)

L’hameçonnage ciblé est un vecteur d’attaque particulièrement efficace, comme le démontre l’attaque debug/chalk de septembre 2025. Les attaquants ont enregistré un faux domaine (npmjs.help) imitant l’infrastructure légitime de NPM.¹¹ Ils ont ensuite envoyé des courriels d’hameçonnage aux mainteneurs de paquets, créant un sentiment d’urgence en affirmant que des mises à jour 2FA étaient requises d’ici une date limite.¹¹ Un mainteneur a été trompé par la supercherie et a saisi son nom d’utilisateur, son mot de passe et son code TOTP sur le faux site, permettant ainsi aux attaquants de prendre le contrôle de son compte.¹⁰

Cette chaîne d’événements montre comment la sécurité d’une infrastructure peut être compromise non pas par une faille technique, mais par une erreur humaine, le facteur le plus imprévisible et souvent le plus faible de la chaîne d’approvisionnement. Le fait que l’attaque ait réussi même avec l’authentification à deux facteurs activée illustre la sophistication de l’ingénierie sociale, qui peut contourner les mesures de sécurité technologiques en ciblant directement l’utilisateur.⁹

2. Les attaques basées sur l’usurpation d’identité (Typosquattage) et les erreurs humaines (Dependency Confusion)

Deux autres vecteurs majeurs exploitent les erreurs des développeurs et la logique des gestionnaires de paquets.

Le typosquattage consiste à publier des paquets malveillants dont le nom est très similaire à celui d’une bibliothèque populaire (par exemple, « lodas » au lieu de « lodash »).¹⁸ Les attaquants espèrent qu’un développeur commettra une faute de frappe lors de l’installation, récupérant ainsi le paquet corrompu au lieu de la version légitime. Bien que simple, cette technique demeure efficace et a conduit à la multiplication de centaines de paquets de ce type sur NPM.²¹
La confusion de dépendances exploite une faille de configuration plus subtile. Elle survient lorsque des organisations utilisent des noms de paquets privés identiques à des paquets qui pourraient exister sur le référentiel public.²² Un attaquant, après avoir découvert le nom d’un paquet interne, peut publier une version malveillante de ce paquet sur le registre public avec un numéro de version plus élevé.²³ Par défaut, de nombreux gestionnaires de paquets privilégient le numéro de version le plus élevé, et si la configuration n’est pas rigoureuse, le système d’automatisation peut télécharger et installer la version malveillante plutôt que la version interne et de confiance.²² Le cas de Microsoft en 2021 est un exemple emblématique de cette vulnérabilité.²³

Ces deux méthodes révèlent un paradoxe : la confiance implicite accordée à l’écosystème open-source et l’automatisation des processus peuvent devenir les principaux vecteurs d’attaque.

3. L’exploitation des mécanismes de publication et des scripts

Le ver Shai-Hulud de septembre 2025 illustre l’abus d’un mécanisme légitime : les scripts de cycle de vie des paquets NPM, en particulier la phase postinstall.²⁴ Cette fonctionnalité est conçue pour permettre aux développeurs d’exécuter du code arbitraire après l’installation d’une dépendance. Les attaquants ont abusé de cette fonction en insérant leur charge utile dans ce script, qui s’exécute automatiquement sur le système du développeur ou dans un environnement de construction CI/CD dès que le paquet est installé.¹⁴ Cette technique transforme une fonctionnalité de commodité en un point d’entrée pour l’exécution de code malveillant sans aucune interaction supplémentaire de la victime, facilitant ainsi la prolifération du ver et le vol de données sensibles.¹⁶

Vecteur d’attaque	Modus Operandi	Exemples récents (2025)	Cibles principales
Phishing / Ingénierie Sociale	Attaque ciblée pour dérober des identifiants et des codes 2FA.	Attaque debug/chalk ¹⁰	Mainteneurs de paquets, développeurs.
Typosquattage	Publication de paquets avec des noms mal orthographiés pour tromper les développeurs.	Paquets de typosquattage ²¹	Développeurs individuels.
Confusion de dépendances	Exploitation de la logique du gestionnaire de paquets pour substituer un paquet interne par une version publique malveillante.	Cas de Microsoft ²³	Systèmes CI/CD, entreprises.
Abus des scripts post-install	Injection de code malveillant dans les scripts de cycle de vie des paquets, qui s’exécutent automatiquement.	Ver Shai-Hulud ¹⁴	Développeurs, systèmes CI/CD.

Partie II. Incidents récents (2025) : analyse des études de cas majeures

A. L’attaque de septembre 2025 sur les paquets debug et chalk

L’incident de septembre 2025, impliquant les paquets debug et chalk, a démontré un scénario d’attaque chirurgical et sophistiqué. La chronologie de l’incident est marquée par une grande rapidité : les versions malveillantes ont été publiées le 8 septembre à 13h16 UTC et ont été retirées du référentiel seulement deux heures plus tard, à 15h20 UTC.¹⁰ Malgré la brièveté de leur disponibilité, des milliers de développeurs ont pu les installer dans cet intervalle.¹⁰ La charge utile était un script JavaScript exclusivement conçu pour les environnements de navigateur, ce qui signifie qu’il ne ciblait pas directement le système d’exploitation ou les fichiers locaux, mais plutôt les actions des utilisateurs finaux.¹⁰

Le maliciel interceptait les appels aux API web et aux portefeuilles de cryptomonnaies (window.ethereum, fetch, XMLHttpRequest).¹⁰ Son objectif principal était de réécrire les transactions en remplaçant les adresses des destinataires par des adresses contrôlées par l’attaquant.¹³ Pour ce faire, il utilisait un algorithme de Levenshtein pour trouver des adresses visuellement similaires, rendant la substitution difficile à détecter pour l’utilisateur.¹¹ Paradoxalement, malgré la gravité perçue de l’attaque et la popularité des paquets affectés, l’impact financier direct a été minime, avec seulement quelques cents de cryptomonnaie volés au total.²⁵

Ce faible rendement soulève des interrogations : l’attaque était-elle un simple test de concept, ou la véritable motivation était-elle la perturbation et la démonstration de force? Plusieurs analyses suggèrent que le coût réel de cet incident n’a pas été le vol de fonds, mais une forme de « déni de service » sur l’ensemble de l’industrie, entraînant des milliers d’heures de travail de remédiation, de vérification des dépendances et de rotation des secrets.¹³ L’incident a par ailleurs créé un marché urgent pour les solutions de sécurité, ce qui pourrait faire partie de l’économie de la menace.²⁵

B. Le ver Shai-Hulud : une nouvelle ère de menace

Le ver Shai-Hulud représente une escalade de la menace, s’appuyant sur l’autonomie et l’automatisation. Son mécanisme de propagation est particulièrement ingénieux et systémique.¹⁴ Après avoir compromis un compte de mainteneur, le ver exécute son script malveillant lors de la phase postinstall du paquet.¹⁴

Ce script recherche et dérobe les jetons d’authentification pour les dépôts NPM, GitHub, et les clés d’accès aux services cloud tels qu’AWS et GCP.¹⁵ Une fois les identifiants volés, le ver identifie les 20 paquets les plus populaires que le mainteneur compromis gère.¹⁶ Il injecte ensuite son propre code dans ces paquets, les modifie pour qu’ils exécutent son script et publie de nouvelles versions corrompues sur le dépôt NPM.¹⁴

L’exfiltration des données est également une technique remarquable. Plutôt que d’envoyer les secrets volés à un serveur central contrôlé par l’attaquant, le ver les publie dans des dépôts GitHub publics nouvellement créés à partir de dépôts privés, en y ajoutant le suffixe -migration.¹⁴ Cette méthode, qui utilise l’infrastructure même de la victime pour exfiltrer les données, rend la détection plus complexe. Le ver Shai-Hulud a également utilisé des outils de sécurité open-source, comme trufflehog, pour rechercher d’autres secrets dans le système de fichiers, ce qui souligne l’évolution des cybercriminels qui intègrent des outils de développement légitimes dans leurs chaînes d’attaque.¹⁴

Caractéristique	Attaque debug/chalk	Ver Shai-Hulud
Date	Septembre 2025 ¹⁰	Septembre 2025 ¹⁶
Vecteur initial	Phishing ciblé sur les mainteneurs ¹¹	Phishing ciblé sur les mainteneurs ¹⁶
Mécanisme principal	Injection de code malveillant dans des paquets populaires ¹⁰	Ver auto-réplicatif exploitant les jetons d’authentification ¹⁴
Cibles principales	Utilisateurs finaux de navigateurs avec des transactions de cryptomonnaie ¹⁰	Mainteneurs de paquets, systèmes de développement, infrastructures cloud ¹⁵
Type de charge utile	Script JavaScript (navigateur) ¹³	Script JavaScript (post-installation) ¹⁴
Impact financier direct	Très faible ²⁵	Non défini, potentiel élevé de vol de secrets ¹⁵
Impact principal	Déni de service industriel, perte de productivité ¹³	Prolifération exponentielle, vol de secrets, compromission de l’infrastructure cloud ¹⁵

Partie III. L’impact systémique et les conséquences multidimensionnelles

Les attaques sur les dépôts NPM ont des conséquences qui dépassent largement les incidents individuels. Elles mettent en évidence des vulnérabilités systémiques qui menacent l’ensemble de l’économie numérique.

A. Évaluation des pertes économiques directes et indirectes

Les pertes économiques ne se limitent pas au vol direct de fonds. Si l’attaque debug/chalk a eu un impact financier direct négligeable, elle a généré des coûts indirects massifs.²⁵ Les entreprises ont dû consacrer des milliers d’heures de travail pour auditer leurs dépendances, revérifier leurs environnements de construction et mettre en place des mesures de remédiation, ce qui équivaut à un « déni de service » pour le secteur.¹³ Ces coûts incluent également les dommages à la réputation, la perte de confiance des clients, et le risque de litiges.²⁶ Les projections financières estiment que les attaques de la chaîne d’approvisionnement coûteront 138 milliards de dollars par an d’ici 2031, reflétant l’ampleur de cette menace à un niveau macroéconomique.⁶ Le ver Shai-Hulud démontre un potentiel de perte financière encore plus important en raison de sa capacité à dérober des clés d’accès à des services cloud, ouvrant la voie à des attaques de rançongiciel, de cryptomining ou de vol de données de grande ampleur.¹⁵

B. Risques pour la sécurité des données et des applications

La compromission d’un compte de mainteneur peut transformer un développeur de confiance en un vecteur d’attaque. Le vol de jetons d’authentification et de clés API (NPM, GitHub, AWS, GCP) ne représente pas seulement une perte de données, mais une porte dérobée vers les systèmes internes de l’entreprise.⁸ Ces identifiants peuvent permettre aux attaquants de pénétrer les environnements de production, de voler des données sensibles stockées dans des compartiments de stockage cloud, de déployer des rançongiciels, ou même de supprimer des environnements entiers.¹⁵

L’impact est systémique : la vulnérabilité d’un seul développeur, dont les paquets sont utilisés par une entreprise, peut conduire à l’infiltration de l’ensemble de l’organisation.

C. L’effet de cascade sur les dépendances transitives

Le modèle de dépendances de l’écosystème NPM, où un paquet simple peut être une dépendance transitive pour des milliers de projets, est la principale source de l’effet de cascade.⁸ Les pipelines CI/CD automatisés sont particulièrement vulnérables, car ils téléchargent et installent les dernières versions des paquets sans intervention humaine, ce qui peut propager une version corrompue dans des centaines d’applications presque instantanément.⁹

Les développeurs peuvent ne pas être conscients que l’application qu’ils construisent contient un paquet malveillant, car il a été inclus par une dépendance indirecte.¹⁰

D. Dommages réputationnels et perte de confiance dans l’open-source

La répétition d’incidents majeurs, où des paquets de confiance sont « empoisonnés », érode la crédibilité de l’écosystème open-source.⁸ Ce modèle, fondé sur la collaboration, la transparence et la fiabilité, est remis en question lorsque sa fondation est corrompue. Cette perte de confiance peut inciter les entreprises à se tourner vers des solutions propriétaires ou à mettre en place des contrôles de sécurité si drastiques qu’ils pourraient ralentir l’innovation et le développement, ce qui va à l’encontre de la raison d’être de l’open-source.

Partie IV. Stratégies de fortification de la chaîne d’approvisionnement NPM

Pour contrer ces menaces, une approche proactive et multicouche est nécessaire, impliquant aussi bien les développeurs que les organisations.

A. Recommandations pour les développeurs et les mainteneurs

Mettre en œuvre l’authentification à deux facteurs (2FA) : L’activation de la 2FA est la première ligne de défense contre les prises de contrôle de comptes.²⁰ Cependant, les mainteneurs doivent être conscients que même la 2FA n’est pas infaillible face à un hameçonnage sophistiqué.⁹
Auditer et verrouiller les dépendances : Il est impératif d’utiliser la commande npm audit pour identifier les vulnérabilités dans les dépendances de votre projet et la commande npm audit fix pour appliquer les correctifs.²⁸ Le verrouillage des versions via le fichier
package-lock.json est crucial pour s’assurer que les paquets installés sont exactement ceux qui ont été audités et approuvés, empêchant ainsi les substitutions malveillantes par des paquets avec des numéros de version supérieurs.²²
Limiter les privilèges et surveiller les secrets : Les développeurs doivent s’assurer que les secrets (clés API, mots de passe) ne sont jamais publiés sur le registre NPM.²⁷ Il est recommandé d’utiliser le paramètre –ignore-scripts lors de l’installation de paquets pour réduire le risque d’exécution de code malveillant via les scripts de cycle de vie.²⁷

B. Mesures de sécurité organisationnelles

Intégrer la sécurité dans le cycle de vie du développement (CI/CD) : La sécurité doit être intégrée dès le début du processus de développement. L’utilisation d’outils d’analyse de la composition logicielle (SCA) et de l’analyse statique du code (SAST) dans les pipelines de construction permet de détecter les vulnérabilités avant que le code ne soit déployé.³² La sécurisation des environnements de construction éphémères est également essentielle pour prévenir le vol de secrets.³²
Adopter des registres et des référentiels de confiance : L’utilisation de registres NPM privés (par exemple, des instances de Nexus ou Artifactory) agit comme un « pare-feu de dépendance ».²⁷ Ces registres permettent aux organisations de contrôler et d’auditer les paquets qui entrent dans leur écosystème, en s’assurant qu’ils sont sûrs avant d’être utilisés par les développeurs. L’utilisation de
scopes pour les paquets internes est une autre mesure préventive efficace contre la confusion de dépendances.²²
Former les équipes et établir des protocoles d’intervention : La sensibilisation aux menaces d’ingénierie sociale et la formation à la reconnaissance des courriels d’hameçonnage sont des mesures humaines qui s’avèrent cruciales.³ Les entreprises doivent également mettre en place des plans de réponse aux incidents pour réagir rapidement en cas d’attaque, notamment en identifiant les paquets compromis, en révoquant les secrets exposés et en communiquant avec les parties prenantes.³⁴

Menace/Vulnérabilité	Mesure de Prévention	Outils/Commandes
Compromission de compte	Activation de l’authentification à deux facteurs (2FA) pour les comptes de publication.	npm profile enable-2fa ²⁷
Vulnérabilités de dépendance	Audit régulier et verrouillage des versions dans le fichier de dépendances.	npm audit, npm audit fix, package-lock.json ²⁸
Typosquattage / Confusion de dépendances	Utilisation de registres privés et de scopes pour les paquets internes.	Registres NPM privés, @votre-organisation/paquet ³³
Exécution de scripts malveillants	Installation de paquets en désactivant l’exécution des scripts de cycle de vie.	npm install –ignore-scripts ²⁷
Publication de secrets	Configuration des fichiers de projet pour exclure les données sensibles.	.npmignore, propriété files dans package.json, npm publish –dry-run ²⁷

Conclusion : Vers une résilience collective

Les attaques contre les dépôts NPM en 2025 ne sont pas des anomalies, mais des illustrations claires d’une menace de la chaîne d’approvisionnement en constante évolution, caractérisée par une professionnalisation, une diversification des vecteurs et une sophistication accrue. Elles démontrent que le simple modèle de confiance de l’écosystème open-source n’est plus suffisant. Le facteur humain, les dépendances transitives et les failles de configuration sont les points d’entrée que les cybercriminels exploitent pour transformer une attaque ciblée en une menace systémique.

La résilience collective de l’écosystème dépend d’une responsabilité partagée. Les mainteneurs doivent fortifier leurs comptes et leurs processus. Les développeurs doivent adopter une posture de « méfiance » en auditant et en verrouillant leurs dépendances. Les entreprises doivent, quant à elles, intégrer la sécurité au cœur de leurs processus de développement et de leur infrastructure CI/CD. La sécurité de la chaîne d’approvisionnement logicielle est un défi complexe, mais la réponse réside dans une combinaison de mesures techniques robustes, d’une vigilance continue et d’une prise de conscience partagée de la menace.

Infographie

https://blog.marcfredericgomez.fr/wp-content/uploads/2025/09/infographienpm.html

Carrousel

Sources des citations utilisées

What is NPM? – GeeksforGeeks, consulté le septembre 20, 2025, https://www.geeksforgeeks.org/node-js/what-is-npm/
What Is NPM? What are Popular Node Packages? | Built In, consulté le septembre 20, 2025, https://builtin.com/software-engineering-perspectives/npm
Qu’est-ce qu’une attaque de la chaîne d’approvisionnement – Keeper Security, consulté le septembre 20, 2025, https://www.keepersecurity.com/fr_FR/threats/supply-chain-attack.html
www.fortinet.com, consulté le septembre 20, 2025, https://www.fortinet.com/fr/resources/cyberglossary/supply-chain-attacks#:~:text=Qu’est%2Dce%20qu’,pour%20infiltrer%20votre%20infrastructure%20num%C3%A9rique.
La cybermenace provenant des chaînes d’approvisionnement – Centre canadien pour la cybersécurité, consulté le septembre 20, 2025, https://www.cyber.gc.ca/fr/orientation/cybermenace-provenant-chaines-approvisionnement
Comprendre les attaques de la chaîne d’approvisionnement logicielle – Xygeni, consulté le septembre 20, 2025, https://xygeni.io/fr/blog/understanding-software-supply-chain-attacks/
Software Supply Chain Attacks To Cost The World $60 Billion By 2025, consulté le septembre 20, 2025, https://cybersecurityventures.com/software-supply-chain-attacks-to-cost-the-world-60-billion-by-2025/
NPM Supply Chain Attack 2025: Crypto & Cybersecurity Risks – Dynamis LLP, consulté le septembre 20, 2025, https://www.dynamisllp.com/knowledge/npm-supply-chain-attack-crypto-security-2025
L’exploit Npm est le point d’entrée, ce qui suit est tout aussi critique. – Vectra AI, consulté le septembre 20, 2025, https://fr.vectra.ai/blog/the-npm-exploit-is-the-entry-point-what-follows-is-just-as-critical
npm Supply Chain Attack: Massive Compromise of debug, chalk, and 16 Other Packages, consulté le septembre 20, 2025, https://www.upwind.io/feed/npm-supply-chain-attack-massive-compromise-of-debug-chalk-and-16-other-packages
Inside the September 2025 NPM Supply Chain Attack – ArmorCode, consulté le septembre 20, 2025, https://www.armorcode.com/blog/inside-the-september-2025-npm-supply-chain-attack
20 paquets JavaScript npm populaires avec 2 milliards de téléchargements hebdomadaires compromis dans une attaque, la plus grande attaque de la chaîne d’approvisionnement de l’histoire ? – Sécurité – Developpez.com, consulté le septembre 20, 2025, https://securite.developpez.com/actu/375617/20-paquets-JavaScript-npm-populaires-avec-2-milliards-de-telechargements-hebdomadaires-compromis-dans-une-attaque-la-plus-grande-attaque-de-la-chaine-d-approvisionnement-de-l-histoire/
Widespread npm Supply Chain Attack: Breaking Down Impact & Scope Across Debug, Chalk, and Beyond | Wiz Blog, consulté le septembre 20, 2025, https://www.wiz.io/blog/widespread-npm-supply-chain-attack-breaking-down-impact-scope-across-debug-chalk
Shai-Hulud: The novel self-replicating worm infecting hundreds of NPM packages – Sysdig, consulté le septembre 20, 2025, https://www.sysdig.com/blog/shai-hulud-the-novel-self-replicating-worm-infecting-hundreds-of-npm-packages
« Shai-Hulud » Worm Compromises npm Ecosystem in Supply Chain Attack (Updated September 19) – Palo Alto Networks Unit 42, consulté le septembre 20, 2025, https://unit42.paloaltonetworks.com/npm-supply-chain-attack/
Self-Replicating Worm Hits 180+ Software Packages – Krebs on Security, consulté le septembre 20, 2025, https://krebsonsecurity.com/2025/09/self-replicating-worm-hits-180-software-packages/
500+ npm Packages Compromised in Ongoing Supply Chain Attack ‘Shai-Hulud’ – Truesec, consulté le septembre 20, 2025, https://www.truesec.com/hub/blog/500-npm-packages-compromised-in-ongoing-supply-chain-attack-shai-hulud
CICD-SEC-3: Dependency Chain Abuse – OWASP Foundation, consulté le septembre 20, 2025, https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-03-Dependency-Chain-Abuse
NPM Typosquatting. NPM (Node Package Manager) is… | by Shane Fast | BACIC | Medium, consulté le septembre 20, 2025, https://medium.com/bacic/npm-typosquatting-6f2f89b3b605
npm: Threats and Mitigations, consulté le septembre 20, 2025, https://docs.npmjs.com/threats-and-mitigations/
NPM : les paquets malveillants se multiplient – Programmez!, consulté le septembre 20, 2025, https://www.programmez.com/actualites/npm-les-paquets-malveillants-se-multiplient-37019
How Dependency Confusion attack works and How to prevent it | Web Security Lens, consulté le septembre 20, 2025, https://www.websecuritylens.org/how-dependency-confusion-attack-works-and-how-to-prevent-it/
5 Examples of Dependency Confusion Attacks – Spectral, consulté le septembre 20, 2025, https://spectralops.io/blog/5-examples-of-dependency-confusion-attacks/
What We Know About the NPM Supply Chain Attack | Trend Micro (US), consulté le septembre 20, 2025, https://www.trendmicro.com/en_us/research/25/i/npm-supply-chain-attack.html
Oops, No Victims: The Largest Supply Chain Attack Stole 5 Cents – Security Alliance, consulté le septembre 20, 2025, https://www.securityalliance.org/news/2025-09-npm-supply-chain
Attaque Phishing : 2,7 Milliards de Packages Compromis – Dimension Internet, consulté le septembre 20, 2025, https://www.dimension-internet.com/attaque-phishing-27-milliards-de-packages-compromis/
NPM Security best practices – OWASP Cheat Sheet Series, consulté le septembre 20, 2025, https://cheatsheetseries.owasp.org/cheatsheets/NPM_Security_Cheat_Sheet.html
npm Security Best Practices you Need to Know – Scantist, consulté le septembre 20, 2025, https://scantist.com/resources/blogs/10-npm-security-best-practices-to-secure-your-applications
www.nodejs-security.com, consulté le septembre 20, 2025, https://www.nodejs-security.com/blog/how-to-use-npm-audit#:~:text=To%20run%20an%20audit%2C%20you,summary%20of%20the%20vulnerabilities%20found.&text=npm%20WARN,dependency%3E%20but%20none%20is%20installed.
The Developer’s Guide to Using NPM Audit to Create a Dependency Tree – Jit.io, consulté le septembre 20, 2025, https://www.jit.io/resources/appsec-tools/guide-to-using-npm-audit-to-create-a-dependency-tree
Why Debian packages are saver then NPM and PyPi – DEV Community, consulté le septembre 20, 2025, https://dev.to/jverhoeks/why-debian-packages-are-saver-then-npm-and-pypi-4j21
Menaces sur la chaîne d’approvisionnement logicielle | Software supply chain security, consulté le septembre 20, 2025, https://cloud.google.com/software-supply-chain-security/docs/attack-vectors?hl=fr
Control your npm packages & avoid dependency confusion – DEV Community, consulté le septembre 20, 2025, https://dev.to/sumstrm/control-your-npm-packages-avoid-dependency-confusion-1cjh
Prévention des actes de malveillance – Cabinet NPM, consulté le septembre 20, 2025, https://cabinetnpm.com/prevention-des-actes-de-malveillance/
Top Cybersecurity Statistics: Facts, Stats and Breaches for 2025 – Fortinet, consulté le septembre 20, 2025, https://www.fortinet.com/resources/cyberglossary/cybersecurity-statistics

CTI & OSINT