L’attaque sans précédent sur NPM relance les débats sur la chaîne d’approvisionnement

Interface chaise-clavier

L’attaque sans précédent sur NPM relance les débats sur la chaîne d’approvisionnement

Dans l’après-midi du 8 septembre, une attaque a eu lieu contre la chaine d’approvisionnement de plusieurs paquets NPM. Les dégâts ont été limités et tout est vite rentré dans l’ordre. Mais les conséquences auraient pu être bien pires, limitées uniquement par les compétences des pirates. L’affaire relance les débats autour de l’authentification et du contrôle de la provenance des modifications.

Le 12 septembre 2025 à 16h53

Commentaires (31)

votre avatar
votre avatar
Précision ajoutée, merci :)
votre avatar
Pourquoi les noms des paquets sont traduits ?
votre avatar
En effet, je ne connais pas nodeJS, mais ces noms me paraissaient bizarre. Une explication serait bienvenue, en ces temps de ronchonnades sur les traductions IA moisies.
votre avatar
backslash, gabarit-craie, supports-hyperliens, has-ansi, simple-swizzle, chaîne-couleur, error-ex, nom_couleur, is-arrayish, tranche-ansi, conversion des couleurs, wrap-ansi, ANSI-Regex, supports-couleur, strip-ansi, craie, déboguer et ansi-styles
On est sur un site genAI ? Faut le rajouter dans l'extension, vite !
votre avatar
Je suis allé voir le lien pour avoir les vrais noms, que je colle ici du coup :
backslash, chalk-template, supports-hyperlinks, has-ansi, simple-swizzle, color-string, error-ex, color-name, is-arrayish, slice-ansi, color-convert, wrap-ansi, ansi-regex, supports-color, strip-ansi, chalk, debug, ansi-styles
votre avatar
L’attaque sans précédent sur NPM relance les débats sur la chaîne d’approvisionnement
Pour moi, ca lance surtout le débat sur deux sujets:
- la complexité de l'écosystème de développement JS qui nécessite d'avoir un gestionnaire de package.
- la confiance que les devs JS accordent à la registry publique de npm (registry.npmjs.org).
votre avatar
en fait, on est plutôt dans la question de la confiance à tout registre public de packages, pas seulement NodeJS, mais aussi Java à travers Maven (souvenir ému de Log4Shell, et c'était pas une attaque !), Python, et, encore pire, Docker.
Je crois qu'il y a un vrai travail en cours sur l'ensemble de ces éléments...
votre avatar
Docker reste potentiellement à mes yeux l'une des pires possibles, puisqu'une image de container jamais mise à jour est un joli paquet cadeau de failles à tous les étages (image de base, runtime, middleware, dépendances...) !
votre avatar
Pour un développeur il n'est pas possible d'auditer sérieusement chaque mise à jour de chaque dépendance, surtout lorsqu'il est exigé de se tenir à jour fréquemment, justement pour combler les failles existantes. Je ne vois guère d'autre option que d'avoir des tiers de confiance. Et ça vaut pour tous les langages, pas seulement JS.

Le problème amha est plutôt le zèle qui est fait pour appliquer les toutes dernières mises à jour: c'est à double tranchant. Il faudrait toujours une petite période de "probation".
votre avatar
Ce qui explique l'importance que commencent à prendre les outils de SCA (Software Composition Analysis), chargés de scanner automatiquement l'ensemble des dépendances d'une application donnée (y compris dans l'idéal les dépendances transitives) pour y détecter celles qui présentent une vulnérabilité.
La fondation OWASP en fournit un basique pour Java et .Net, on en trouve des plus perfectionnés — rarement en open source par contre.
votre avatar
Je recommande Grype qui a un éventail de plateformes/langages supportés assez large github.com GitHub
votre avatar
C'est aussi loin d'être la panacée, ces outils. Peut-être que certains sont meilleurs que d'autres, je connais pas tout, mais bien souvent c'est la foire aux faux positifs tout simplement parcequ'ils s'arrêtent à l'analyse du SBOM sans chercher à déterminer si le code est effectivement vulnérable ou pas (ce qui est autrement plus difficile à montrer).
Exemple simple et courant, une CVE dans golang net/http concernant http2 sera généralement remontée à tous les consommateurs du package peu importe si http/2 est effectivement actif ou pas. Ou une vulnérabilité au ddos sur un type de regex qu'on n'utilise de toute façon pas.
Selon les dépendances, ça peut être plus ou moins gênant. Certaines s'updatent facilement, d'autres entraînent leur lot de breaking changes qui peuvent être un casse-tête à gérer... Tout ça juste pour "satisfaire" les scanners de vulnérabilité et leurs faux positifs.
votre avatar
Les pull-requests ne doivent pas être validées par d'autres dev avant de passer en prod ?
votre avatar
Si tu es tout seul sur ton projet open source, ce n'est pas possible.

Après, vient tout le débat de la confiance en la personne et comment être certains que c'est bien elle.
Pour Linux, M. Torvald vérifie les PRs avec son compte. Si son compte est piraté pour valider une PR vérolée, le résultat est vérolée.
Dans ce cas là, nous sommes sauvé par la communauté de testeurs et le délai avant la distribution. Mais il faut qu'une personne compétente ait le temps de tomber dessus.

Pour les petites librairies, il n'y a ni les personnes, ni les compétences et c'est livré directement.
Pour les développeurs les utilisant, on peut "retarder" le passage à la nouvelle version en espérant que quelqu'un d'autre essuie les plâtres. Mais si tout le monde fait ça, on revient à la problématique de base.
On tombe actuellement sur la "solution magique" de l'IA vendue pour s'assurer que c'est bon...

On peut aussi se baser des librairies. Certaines encapsulaient des RegEx, donc, si on s'en aperçoit, on s'en passe. D'autres permettent d'éviter d'entrer dans certains contenus compliqués comme les dessins vectoriels...
votre avatar
Certaines libraries sont nécessaires dans certains projets (au hasard React et ses milliards de dépendances, ou encore discord.js si tu veux créer un bot discord) d'autres peuvent être recodée en 2secondes (is-number :'))

Dans tous les cas sur des projets qui embarquent beaucoup de dépendances (souvent le cas sur du React) ça peut vite devenir impossible de tout vérifier.

On peut cependant espérer que les gestionnaires de packets (ainsi que npm/pnpm/bun/deno...) fassent un minimum d'effort pour éviter des dingueries.
votre avatar
Tout à fait d'accord.

Après, j'ai l'impression que le web est plus sujet à être géré par des "bidouilleurs". Ils ne prennent même pas la peine de questionner les dépendances.

J'étais arrivé dans une équipe "fullstack" avec React sur un projet tout récent (3 mois).
Ils avaient juste fait un copier-coller des dépendances sans réfléchir. Résultat, il y avait déjà une quarantaine de dépendances dont certaines avec des versions de plus de 3 ans. Et personne ne s'était posé de question. J'ai passé deux semaines pour tout vérifier, supprimer 3/4 des librairies car inutilisées et mis à jour le reste.

Il y a toute une culture à changer chez les développeurs et encore plus dans les technos webs qui sont maltraitées.
Ce n'est pas normal de crouler sous les librairies sans pouvoir en expliquer l'utilité.
Certains ne font pas que "pisser" du code en se cachant derrière le framework utilisé : "je suis obligé pour que ça fonctionne" 😥
votre avatar
Un des soucis dans toute cette histoire c'est qu'il n'y a toujours pas de moyen général d’authentifier la provenance des e-mail.
votre avatar
Non. Le problème est comme d'habitude un problème d'interface chaise clavier.
L'e-mail venait bien d'où il disait, un domaine créé pour cette opération quelques jours plus tôt.

Ensuite, s'il suffit que l'on fasse un commit dans un dépôt dans github pour que ça soit à la disposition de tous dans l'heure qui suit, il y a un énorme problème de process. Je sais bien que tester, c'est douter, mais depuis quand on publie du logiciel qui n'a subit aucun test qui vérifie que l'ensemble des commits sont bien valides ?
L'absence d'authentification à double facteur est aussi criminelle.
votre avatar
Il y a surtout une très grosse négligence de la personne concernée qui a saisi des identifiants sur un site qui n'était pas le bon.

Pourtant, les gestionnaires de mot de passe comme protonpass, 1password & Co sont très répandus. Ils constituent une bonne défense contre le hameçonnage car ils ne suggèrent de saisir le login et le mot de passe que si on est sur le bon site. C'est l'une des raisons pour laquelle l'ANSSI conseille l'usage des gestionnaires de mots de passe.

Avoir une double authentification incluant une passkey est aussi une solution car chaque passkey est lié à un unique site et si on est sur un site de hameçonnage, la passkey ne sera pas proposée/ ne marchera pas.

C'est fou de voir des informaticiens passer à côté de mesures de base et se faire avoir.
votre avatar
Tout dans JavaScript & consorts, du langage jusqu'à la chaine d'approvisionnement des paquets NPM, est à vomir.
Mais aujourd'hui, même les plus simples des sites Web sont générés avec cette chose.

Vous souvenez-vous de https://arxiv.org/abs/2112.10165 ?

Je ne compte plus les aberrations dans cet écosystème. L'argument du manque de gens ne fait pas long feu : d'autres projets aussi peu humainement chanceux n'ont pas la porte béante réclamant les problèmes à ce point.
Il y a un problème de fond avec cet écosystème : peut-être n'y a-t-il tout simplement pas assez de gens compétents à la mise en place & gestion d'une infrastructure d'approvisionnement qui s'y intéressent.
votre avatar
"L’attaque sans précédent sur NPM"
"la société belge rappelle une autre compromission qui s’est déroulée fin août"
votre avatar
votre avatar
J'ai jamais entendu parler de ce genre de soucis avec pypi.org (comme NPM mais côté Python). C'est que c'est mieux foutu ? Ou juste que c'est moins médiatisé ?
votre avatar
Les packages python malveillants sont pourtant régulièrement dézingués et Python est tout autant attaqué par les patterns de supply chain. La seule diff que je vois, c'est que l'un est géré par GitHub / Microsoft, l'autre non.

Pypi propose le MFA sur ses comptes, mais il ne l'impose pas à ma connaissance.
votre avatar
Il me semble justement que le MFA est obligatoire sur Pypi depuis quelque temps (voir ici).

Par contre, c'est uniquement si tu es mainteneur d'un paquet.
votre avatar
J'avais cherché dans les ToS de Pypi.org avant de poster justement, ils ne contraignent à rien dedans.

Je me demande si c'est vraiment d'actualité ou s'ils ont oublié un truc :D
votre avatar
Je viens de voir cet article de Korben : https://korben.info/github-immutable-releases-fin-attaques-supply-chain.html

Je ne suis pas compétent niveau code mais il se pourrait qu'il y ai un début de solution à adapter à npm and co.
votre avatar
Ça évite de compromettre une release existante, mais ça n'empêche pas de créer une nouvelle release compromise, qui sera téléchargée lors des updates de dépendances. Donc c'est bien mais pas suffisant ...
votre avatar
Par ailleurs il semble que c'est déjà le principe de fonctionnement de npm: npm publish
Once a package is published with a given name and version, that specific name and version combination can never be used again, even if it is removed with npm unpublish.
votre avatar
La gueule des dépendances sérieusement, qui a besoin d'un "color-string" / "color-convert" ?
Ce type de lib n'a aucune raisons d'être et encore moins d'être mis à jour (enfin à chaque fois qu'il y'a une nouvelle couleur :mdr2: )
Franchement on parle d'une division et d'un modulo, pourquoi créer une dep externe pour si peu ?
ça illustre la médiocrité d'un grand nombre de "dev" web : des incompétents biberonnés au copier / coller depuis stack overflow, ceux-là même qui t'expliquent gagner du temps grâce à l'IA. Forcément si tu passais 4h sur google à chercher un framework qui fait une division, autant faire un prompt le résultat sera tout aussi incertain (est-cela bonne division ? )

L’attaque sans précédent sur NPM relance les débats sur la chaîne d’approvisionnement

  • L’ingénierie sociale, toujours elle

  • Tout s’enchaine très vite

  • L’authentification des développeurs à nouveau en question

Fermer