npm 12 : une protection clé contre les attaques logicielles

Vos développeurs utilisent chaque jour des centaines de petites briques logicielles gratuites pour construire vos applications. C'est pratique, rapide… et risqué. Car depuis quelques années, des pirates s'infiltrent discrètement dans ces briques pour y glisser des malwares. Bonne nouvelle : npm, l'outil le plus utilisé au monde pour gérer ces briques, vient de franchir un cap important avec sa version 12. Il bloque désormais par défaut les scripts d'installation, l'une des principales portes d'entrée de ces attaques. Voici ce que ça change concrètement pour votre PME.

Le problème : des malwares cachés dans des outils du quotidien

Imaginez que vos développeurs commandent chaque matin des fournitures auprès de dizaines de fournisseurs différents. La plupart sont fiables. Mais si un seul d'entre eux glisse un produit contaminé dans sa livraison, tout votre bureau est exposé. C'est exactement ce qu'on appelle une attaque sur la chaîne logicielle — ou supply chain attack en anglais. Des pirates compromettent un package open source populaire, y ajoutent un code malveillant, et attendent que des milliers d'entreprises l'installent sans s'en rendre compte. Ces packages sont téléchargés via npm, un gestionnaire de paquets utilisé massivement dans le développement web. Parmi les fonctionnalités les plus dangereuses : les scripts d'installation. Ce sont des petits programmes qui s'exécutent automatiquement dès qu'un développeur installe un package. Pratiques en théorie, ils sont devenus l'outil favori des attaquants pour exécuter du code malveillant à l'insu de tout le monde. Pour la npm sécurité PME, ce risque est trop souvent sous-estimé.

Ce que change npm 12 : moins d'automatisme, plus de contrôle

Avec npm 12, le comportement par défaut change radicalement : ces scripts d'installation ne s'exécutent plus automatiquement. Concrètement, quand votre équipe installe un nouveau package, le script qui l'accompagne est mis en attente. Il ne s'exécute que si un développeur le valide explicitement. C'est un peu comme passer d'une livraison automatique sans contrôle à un système où chaque colis est inspecté avant d'entrer dans vos locaux. Ce changement ne règle pas tout, mais il brise une étape clé du mécanisme d'attaque. Un code malveillant qui ne s'exécute pas, c'est un code qui ne fait pas de dégâts. Pour les PME qui n'ont pas de responsable sécurité à temps plein, c'est une protection précieuse qui s'active sans effort particulier.

Pourquoi les PME sont particulièrement exposées à ces attaques

On pourrait croire que les pirates ne s'intéressent qu'aux grandes entreprises. C'est faux. Les PME représentent des cibles de choix pour plusieurs raisons : elles utilisent autant d'outils open source que les grands groupes, mais avec moins de ressources pour surveiller ce qui est installé sur leurs machines. Une attaque sur la chaîne logicielle ne cible pas forcément votre entreprise directement — elle vise un outil que vous utilisez, comme tout le monde. Et les conséquences peuvent être graves : vol de données clients, accès à vos systèmes internes, rançongiciel. Des incidents de ce type ont déjà touché des milliers d'entreprises à travers le monde via un seul package compromis. La chaîne logicielle attaque n'est pas un scénario de science-fiction : c'est une réalité documentée et en forte croissance depuis 2020.

Ce que vous pouvez faire dès maintenant

1. Demandez à votre équipe technique de vérifier la version de npm utilisée sur tous les postes de développement. La version 12 doit être déployée dès que possible pour bénéficier de la protection par défaut.

2. Mettez en place une politique simple : tout nouveau package open source doit être validé avant utilisation en production. Même une vérification rapide sur des bases de données de vulnérabilités connues (comme le site osv.dev) peut faire la différence.

3. Activez les alertes de sécurité automatiques sur vos dépôts de code (GitHub, GitLab…). Ces plateformes signalent gratuitement les packages à risque intégrés dans vos projets.

4. Sensibilisez vos développeurs : rappeler régulièrement que les supply chain attacks existent et qu'un package populaire peut être compromis suffit souvent à installer de bons réflexes.

5. Si vous externalisez votre développement, demandez à votre prestataire de vous confirmer par écrit qu'il applique une politique de gestion des dépendances open source. C'est une question légitime, et un bon prestataire saura y répondre.