GitHub est sur le point de provoquer l’un des changements de sécurité les plus importants de l’écosystème JavaScript ces dernières années. Donc, si vous n’avez pas encore lu sur npm 12, c’est le moment idéal pour comprendre ce qui est en jeu avant l’arrivée de juillet.
GitHub et le problème que personne n’osait admettre
Pendant longtemps, l’exécution automatique de scripts lors de l’installation npm a fonctionné comme une porte ouverte au milieu d’un coffre-fort. En effet, chaque paquet installé, y compris toutes ses dépendances transitives, avait la permission d’exécuter du code arbitraire sur votre machine ou sur votre serveur CI/CD.
Cela signifie qu’un seul paquet compromis, enfoui trois niveaux plus bas dans votre arbre de dépendances, pouvait suffire à compromettre tout l’environnement. Le ver Shai-Hulud est un exemple concret de ce vecteur d’attaque en action. Ainsi, la vulnérabilité n’était pas hypothétique; elle était déjà exploité activement.
Comme l’a souligné le mainteneur Leo Balter, les scripts de cycle de vie représentent la plus grande surface d’exécution de code dans l’ensemble de l’écosystème npm. Par conséquent, la décision d’agir n’était pas surprenante, mais elle est arrivée tardivement.
Ce que GitHub change définitivement dans npm 12
La version 12, prévue pour juillet 2026, arrive avec trois modifications qui impactent le comportement par défaut de l’outil :
Les scripts de cycle de vie seront bloqués par défaut. Les configurations en preinstall, install et postinstall ne s’exécutent plus automatiquement. Pour autoriser un script spécifique, il faut le déclarer explicitement via allow-scripts.
Téléchargement via Git désactivé. Le drapeau allow-git sera désactivé par défaut. Par conséquent, cela élimine le vecteur par lequel un fichier .npmrc malveillant pourrait écraser l’exécutable Git et rediriger l’exécution.
Dépendances distantes bloquées. Le drapeau allow-remote prend désormais la valeur none par défaut. En d’autres termes, les dépendances ne peuvent plus être téléchargées à partir de sources externes sans autorisation explicite.
Ce que vous devrez probablement revoir avant le lancement de npm 12
Si votre projet utilise des modules natifs compilés au moment de l’installation, ou des outils tels que Playwright, Puppeteer et Electron, vous constaterez probablement des ruptures. Ces outils dépendent des scripts postinstall pour télécharger des binaires, et auront donc besoin d’une liste blanche (allowlist) configurée dans le package.json.
De plus, il y a un détail important concernant les conflits de configuration. Si vous avez déjà ignore-scripts défini sur true dans votre environnement, il écrasera la nouvelle configuration allow-scripts. Ainsi, retirez ignore-scripts avant d’adopter le nouveau standard, sinon les listes d’autorisations que vous configurerez seront ignorées.
La recommandation actuelle est de commencer dès maintenant à ajuster ces drapeaux dans le fichier .npmrc ou via des variables d’environnement, avant l’arrivée de la version 12.
Est-ce que cela résout le problème une bonne fois pour toutes ?
Pas entièrement. Une partie de la communauté a déjà signalé que ce changement, bien que nécessaire, ne ferme pas toutes les failles. En pratique, un logiciel malveillant pourrait simplement déplacer le code malveillant du script d’installation vers le module lui-même, qui s’exécute toujours normalement.
À noter, d’ailleurs, que des gestionnaires tels que pnpm, Yarn Berry, Bun et Deno avaient déjà mis en œuvre ces restrictions par défaut il y a longtemps. En somme, npm rejoint, essentiellement, une norme de sécurité que une partie de l’écosystème considérait déjà comme basique.
GitHub et la chaîne d’approvisionnement: que faire maintenant
Cette modification constitue un breaking change réel. Plutôt que d’attendre juillet pour découvrir ce qui aurait été cassé, l’option la plus avisée est d’auditer dès maintenant quels paquets de votre projet dépendent des scripts de cycle de vie, de bâtir la liste d’autorisations correspondante et de tester le comportement avec les nouveaux drapeaux actifs.
La sécurité de la chaîne d’approvisionnement n’est pas un problème qui se résout par une seule mise à jour. Cependant, retirer l’exécution automatique de scripts arbitraires de l’équation est, sans aucun doute, un pas dans la bonne direction.
Acessez notre profil sur Instagram !
