npm 12 : moins de malwares cachés dans vos logiciels

Imaginez que vous commandez un meuble en kit. La livraison arrive, vous ouvrez la boîte… et un petit robot caché dedans commence à fouiller votre appartement à votre insu. C'est exactement ce que permettaient certaines failles dans les outils utilisés quotidiennement par vos développeurs ou prestataires techniques. GitHub vient d'annoncer un changement majeur dans npm 12 — l'outil le plus utilisé au monde pour construire des applications web — qui réduit concrètement ce risque. Bonne nouvelle pour votre PME. Encore faut-il savoir ce que cela implique.

C'est quoi npm, et pourquoi ça vous concerne ?

npm (Node Package Manager) est une sorte de supermarché de briques logicielles. Quand vos développeurs construisent un site, une application ou un outil interne, ils n'écrivent pas tout de zéro : ils utilisent des centaines de petits morceaux de code préfabriqués, appelés « dépendances », qu'ils téléchargent via npm. C'est pratique, c'est rapide. Mais c'est aussi une porte d'entrée. Chacune de ces briques peut contenir du code malveillant, installé sans que personne ne s'en rende compte. On appelle ça une attaque sur la chaîne d'approvisionnement logicielle — ou supply chain attack. Ce type d'attaque est en forte hausse : selon Sonatype, les incidents liés à la chaîne d'approvisionnement logicielle ont augmenté de plus de 700 % en trois ans. Et les PME, souvent moins surveillées que les grands groupes, sont des cibles de choix.

Le problème des scripts d'installation : une bombe à retardement silencieuse

Jusqu'ici, lorsqu'un développeur installait une dépendance npm, des « scripts d'installation » pouvaient s'exécuter automatiquement dans la foulée — sans demander la moindre permission. Ces scripts, c'est du code qui tourne directement sur la machine de votre développeur, ou sur votre serveur. Dans la plupart des cas, c'est légitime et utile. Mais dans certains cas — de plus en plus fréquents — des cybercriminels glissent dans ces scripts des logiciels espions, des voleurs de mots de passe ou des portes dérobées. Le tout s'installe en silence, en quelques secondes, au moment où votre équipe technique met à jour ses outils. C'est précisément ce mécanisme qui a permis des attaques retentissantes comme celle sur SolarWinds ou, plus récemment, plusieurs incidents impliquant des packages npm piégés ciblant des entreprises de taille moyenne. La sécurité npm était donc en jeu à chaque simple mise à jour de code.

Ce que npm 12 change concrètement : le principe du « non par défaut »

Avec npm 12, GitHub adopte une logique de sécurité beaucoup plus saine : les scripts d'installation sont désormais désactivés par défaut. Concrètement, aucun code tiers ne peut plus s'exécuter automatiquement lors de l'installation d'une dépendance — sauf si votre équipe technique l'autorise explicitement, package par package. C'est un changement de paradigme important. On passe d'un modèle « tout est autorisé sauf ce qui est interdit » à un modèle « rien n'est autorisé sauf ce qui est explicitement validé ». Pour votre PME, cela signifie une réduction significative du risque d'infection silencieuse via la chaîne d'approvisionnement logicielle. Un attaquant qui aurait glissé un script malveillant dans une dépendance se retrouvera bloqué par défaut, avant même que quiconque ait eu le temps de s'en rendre compte. C'est un filet de sécurité supplémentaire, automatique, sans effort de votre part — à condition d'anticiper la migration.

Ce que vous pouvez faire dès maintenant

Ce changement est une bonne nouvelle, mais il peut créer des blocages temporaires si vos équipes ou prestataires ne s'y préparent pas. Voici ce qu'il faut mettre en place avant la bascule vers npm 12 :

1. Parlez-en à vos développeurs ou prestataires dès cette semaine. Posez-leur simplement la question : « Êtes-vous au courant du changement npm 12 et avez-vous évalué son impact sur nos projets ? » C'est un signal fort que la sécurité de la chaîne d'approvisionnement logicielle est sur votre radar.

2. Demandez un audit des dépendances actives. Vos projets utilisent probablement des dizaines, voire des centaines de packages npm. Certains ont des scripts d'installation légitimes qui devront être réactivés manuellement après la migration. Mieux vaut en dresser la liste maintenant que découvrir les pannes le jour J.

3. Intégrez une vérification de sécurité npm dans vos routines. Des outils comme npm audit (intégré gratuitement) ou des solutions tierces permettent de détecter les packages connus pour être malveillants. Demandez à votre équipe technique de l'activer à chaque mise à jour.

4. Mettez à jour vos contrats prestataires. Si vous externalisez votre développement, assurez-vous que vos contrats mentionnent explicitement la responsabilité de suivre les bonnes pratiques de sécurité npm et les mises à jour majeures d'outils comme npm.

5. Planifiez la migration npm 12 sur un environnement de test. Ne laissez pas vos prestataires faire la mise à jour directement en production. Toute migration majeure doit d'abord être validée dans un environnement isolé pour éviter les interruptions de service.

La supply chain attack est aujourd'hui l'un des vecteurs d'attaque les plus redoutables contre les PME — précisément parce qu'elle passe par des outils de confiance. npm 12 n'est pas une solution miracle, mais c'est une avancée réelle. Profitez-en pour en faire un sujet de conversation avec votre équipe technique cette semaine.