npm 12 bloque les scripts d'installation : une bonne nouvelle pour vos logiciels
Publié le 8 juillet, npm 12 n'exécute plus par défaut les scripts d'installation des dépendances, la porte d'entrée des attaques récentes. Ce que ça change pour vos projets.
Le 8 juillet, la version 12 de npm, l'outil qui installe les composants des applications JavaScript, a été publiée avec un changement attendu depuis longtemps : les scripts d'installation des dépendances ne s'exécutent plus par défaut. C'est précisément par ce mécanisme que passaient plusieurs attaques récentes, dont celle qui a touché des paquets de Red Hat début juin. Pour une PME qui fait développer des applications, c'est une bonne nouvelle, avec une contrepartie : certains projets devront être ajustés.
Ce qui change avec npm 12
D'après les notes de version publiées sur le dépôt officiel de npm :
- Les scripts de cycle de vie des dépendances sont bloqués par défaut, sauf si la politique allowScripts du projet les autorise. Après l'installation, le développeur enregistre les autorisations nécessaires, puis relance la construction des paquets approuvés.
- Les dépendances tirées directement d'un dépôt Git ou d'une adresse web sont refusées par défaut : il faut les autoriser explicitement.
- Les versions de Node.js prises en charge sont désormais les branches 22 (à partir de 22.22.2), 24 (à partir de 24.15.0) et 26 et suivantes.
- La commande npm adduser disparaît : les comptes se gèrent sur le site de npm.
Selon The Hacker News, ces changements avaient été annoncés par GitHub, qui gère npm, dès le mois de juin, avec une version intermédiaire qui affichait des avertissements pour préparer la transition.
Pourquoi c'est important
Une application JavaScript moderne s'appuie sur des centaines de composants, qui en tirent eux-mêmes d'autres. Jusqu'ici, chacun de ces composants pouvait embarquer un script exécuté automatiquement au moment de l'installation, sur le poste du développeur ou sur le serveur qui construit l'application.
C'est exactement ce qu'exploitait l'attaque contre les paquets de Red Hat, dont nous parlions dans notre article du 3 juin : un script de pré-installation lançait un programme qui volait les clés d'accès aux clouds, aux dépôts et aux serveurs. Avec npm 12, ce script ne se serait pas exécuté sans une autorisation explicite.
Le changement ne supprime pas tous les risques. Un composant piégé peut toujours contenir du code malveillant qui s'exécute quand l'application l'utilise. Mais il ferme la voie la plus simple et la plus discrète, celle qui frappait au moment de l'installation, avant même que quiconque ait lancé l'application.
La contrepartie : des projets à ajuster
Certains composants légitimes ont besoin de leur script d'installation, notamment ceux qui compilent du code natif (traitement d'images, chiffrement, accès à du matériel). Sur un projet qui passe à npm 12 sans préparation :
- l'installation peut sembler réussir, mais certains composants ne fonctionnent pas, faute d'avoir été construits ;
- la chaîne de construction automatique peut échouer tant que la liste des scripts autorisés n'a pas été établie et enregistrée dans le projet ;
- les projets qui tournent sur une version de Node.js trop ancienne ne pourront pas utiliser npm 12 du tout.
Rien de grave pour un projet suivi : établir la liste des scripts autorisés prend peu de temps, et c'est une occasion de vérifier que chacun est justifié. Un composant qui exige un script d'installation sans raison évidente mérite d'ailleurs une question : pourquoi en a-t-il besoin, et peut-on le remplacer par une alternative qui fournit des fichiers déjà compilés ? Le passage à npm 12 est donc aussi une occasion de passer vos dépendances en revue, à condition de le faire avec méthode plutôt que d'autoriser tous les scripts en bloc pour que la construction repasse au vert. Autoriser tout, c'est revenir exactement à la situation d'avant. Pour un projet que personne ne maintient, en revanche, c'est le genre de changement qui casse une mise à jour urgente le jour où on en a besoin.
Les questions à poser à votre prestataire
- Sur quelle version de Node.js et de npm tournent nos applications ? Sont-elles encore maintenues ?
- Le passage à npm 12 est-il planifié ? La liste des scripts autorisés a-t-elle été établie et relue ?
- Les dépendances sont-elles figées par un fichier de verrouillage, et relues avant mise à jour ?
- Les serveurs qui construisent l'application n'ont-ils accès qu'aux secrets strictement nécessaires ?
Ces questions relèvent de la maintenance courante d'un logiciel, celle qui ne se voit pas quand tout va bien. Elle est incluse dans les abonnements que nous proposons sur nos logiciels, avec une réponse sous 24 heures ouvrées. Si vous avez un doute sur l'état de maintenance d'une application existante, un rendez-vous de 30 minutes, gratuit, permet d'y voir clair.