🕵️ Un rappel des faits (ou l’art de la répétition)
Depuis plus d’un an, les attaques contre la supply chain NPM sont devenues un sport de compétition internationale. Chaque semaine (ou presque), on découvre :
- des packages piégés publiés par des pseudo-contributeurs,
- des typosquats (vous tapezÂ
expresss au lieu deÂexpress, et bam, un malware en cadeau), - des packages dĂ©tournĂ©s suite au vol de comptes mainteneurs,
- et bien sûr, les scripts post-install qui exécutent des charges malicieuses direct chez vous, sans même vous demander si vous avez envie de participer au bingo des ransomwares.
Pendant ce temps, GitHub (propriétaire de NPM depuis 2020) s’est contenté de coller des rustines, comme un mécano qui met du scotch sur un réacteur d’avion en plein vol. Résultat : une érosion massive de confiance dans l’écosystème JavaScript, déjà bien connu pour sa dépendance pathologique à des modules de trois lignes de code maintenus par des étudiants insomniaques.
Retour sur les problèmes NPM
🔥 Les attaques marquantes (chronologie du chaos)
Petit best of, juste pour se remémorer le feuilleton :
- 2021 : EventStream – Le package open source est compromis pour miner des cryptos. Bien avant le rachat par GitHub, mais le signal était clair : “Houston, on a un problème.”
- 2022 : ua-parser-js – 7 millions de téléchargements/semaine, infiltré par un malware qui installe un voleur de mots de passe. Ambiance garantie.
- 2023 : packageÂ
colors etÂfaker.js – Le mainteneur dĂ©cide de “troller” et casse dĂ©libĂ©rĂ©ment son propre code. MoralitĂ© : la supply chain n’a pas besoin d’attaquants, parfois ce sont les devs eux-mĂŞmes qui sabotent. - 2024 : XZ Utils – Pas NPM, mais un coup de maĂ®tre de supply chain qui a traumatisĂ© tout le monde. Depuis, les attaquants savent que la patience paie.
- 2025 : Typosquats et comptes volés à répétition. Chaque semaine, des malwares passent entre les mailles et infectent des milliers de projets. Oui, chaque semaine.
🛡️ Les mesures annoncées (mieux vaut tard que jamais ?)
GitHub sort enfin de son sommeil avec trois annonces phares :
- Publication locale obligatoire avec 2FA – Finies les publications sauvages avec juste un mot de passe. On impose une double authentification. (Applaudissements en fond de salle, mais on aurait aimé ça en 2022).
- Tokens granulaires avec expiration de 7 jours – Terminé le “token à vie” qui traîne sur un vieux laptop oublié. Désormais, ça s’autodétruit. (Oui, comme Snapchat, sauf que là c’est sérieux).
- Trusted publishing – Des mécanismes pour lier directement la CI/CD au registre, sans intermédiaire foireux. On serre les vis sur la chaîne.
Soyons clairs : ces mesures vont dans le bon sens. Mais pourquoi avoir attendu des mois de carnage médiatique et des tonnes de projets compromis pour les mettre en place ?
🤡 Le malaise persistant
Le vrai problème reste la culture du “publish fast, break things” dans l’écosystème JavaScript. Quelques chiffres pour mesurer l’ampleur du désastre :
- Plus de 2,5 millions de packages sur NPM.
- Une dépendance moyenne de plus de 1 000 packages dans une seule app web moderne.
- Des mainteneurs bénévoles (souvent fatigués et sous-payés) qui se retrouvent en première ligne face à des groupes APT.
Résultat ? Les DSI doivent aujourd’hui considérer NPM comme un territoire miné. On ne parle plus d’open source mais de roulette russe logicielle.
🧩 Et maintenant ?
GitHub a beau annoncer des réformes, l’écosystème a déjà montré sa fragilité. Les prochaines étapes devraient inclure :
- Scanning proactif et obligatoire des packages avant publication, pas après coup.
- Audit de code automatisé renforcé (type sigstore + vérification cryptographique des builds).
- Soutien financier aux mainteneurs critiques, parce que la sécurité ne peut pas reposer uniquement sur la bonne volonté.
Sinon, on continuera de découvrir chaque lundi matin le nouveau package piégé du week-end, comme un épisode d’une série Netflix sans fin.
⚡ Conclusion
GitHub a enfin décidé d’agir, mais soyons honnêtes : la maison brûle depuis longtemps. Ces annonces ressemblent à un pompier qui arrive après l’incendie, l’extincteur à la main, fier de dire “regardez, j’ai de la mousse”.
La morale ? Tant que les développeurs continueront à installer des dépendances comme on collectionne des stickers Panini, et tant que GitHub ne traitera pas la sécurité comme une priorité absolue plutôt qu’un correctif de dernière minute, les attaques sur la supply chain NPM resteront notre pain quotidien.
Et vous, chers devs, la prochaine fois que vous tapez npm install, souvenez-vous : c’est peut-être la commande la plus risquée de toute votre journée.
