npm v12 : la fin des scripts d’installation automatiques

npm v12 : la fin des scripts d'installation automatiques

Temps de lecture : 5 min

Points clés à retenir

  • Sécurité renforcée : npm v12 bloque par défaut l’exécution automatique des scripts d’installation, un vecteur d’attaque majeur.
  • Changement de philosophie : Les développeurs doivent explicitement autoriser les scripts, instaurant une gouvernance de la chaîne d’approvisionnement.
  • Conformité réglementaire : Cette mise à jour répond aux exigences de la loi européenne sur la cyber-résilience.

Pourquoi GitHub modifie-t-il les paramètres par défaut de npm ?

En juillet 2026, GitHub a annoncé un changement majeur dans le gestionnaire de paquets npm. La version 12 de npm install bloquera par défaut l’exécution automatique des scripts d’installation (preinstall, install, postinstall). Ce vecteur d’attaque, exploité régulièrement pour propager des logiciels malveillants via la chaîne d’approvisionnement, devient ainsi une fonction à activer explicitement.

Ce qui change concrètement : la valeur par défaut de l’option « allowScripts » passe à « false ». Les builds node-gyp et les scripts implicites sont également bloqués. Les développeurs conservent la possibilité d’activer cette fonctionnalité, mais la sécurité par défaut est désormais privilégiée.

Une réaction tardive mais bienvenue

En pratique, cette mesure était réclamée depuis des années. Des concurrents comme Yarn, pnpm et Bun bloquaient déjà les scripts tiers par défaut. Comme le souligne Sanchit Vir Gogia, analyste en chef chez Greyhound Research : « npm n’invente pas une nouvelle doctrine, il en adopte enfin une. » Mais, soyons clairs, ce retard s’explique aussi par des considérations de compatibilité. De nombreux paquets légitimes (installateurs de navigateurs, hooks Husky, builds Electron) utilisaient ces scripts pour leur fonctionnement.

Ce qui fait vraiment la différence : la sécurité proactive

Cette évolution ne supprime pas tous les risques liés à la chaîne d’approvisionnement, mais elle en réduit considérablement un vecteur majeur. Sonu Kapoor, responsable de la maintenance de CVE Lite CLI chez OWASP, prévient : « Cela ferme une porte très dangereuse, mais ne sécurise pas toute la maison. » Les attaquants peuvent toujours exploiter le typosquatting, les comptes compromis ou les workflows GitHub Actions.

Avantages clés :

  • Réduction drastique des attaques automatisées.
  • Mise en place d’une gouvernance logicielle avec traces vérifiables.
  • Conformité avec les réglementations comme la loi européenne sur la cyber-résilience.

Les limites à prendre en compte

Comme le note Alan Parkinson, directeur de Threat Detective, « les acteurs les plus compétents se tournent déjà vers d’autres méthodes ». Le paramètre par défaut de npm v12 ne bloque que les attaquants les moins sophistiqués. Ce qui fait vraiment la différence, c’est l’adoption d’une approche de confiance zéro (zero trust) sur l’ensemble de l’écosystème.

Comment se préparer à cette transition ?

En pratique, les équipes de développement doivent anticiper les impacts de cette mise à jour. Voici les étapes à suivre :

  • Auditer les dépendances : Identifier les paquets qui utilisent des scripts d’installation (avec npm audit ou des outils comme Snyk).
  • Planifier les autorisations : Pour chaque paquet légitime, ajouter explicitement « allowScripts » dans le fichier package.json.
  • Former les développeurs : Expliquer pourquoi ce changement sécurise l’entreprise et comment gérer les blocages.

Pour les projets utilisant des builds natifs ( node-gyp), l’impact est immédiat : ils seront bloqués jusqu’à autorisation manuelle. Les équipes CI/CD doivent aussi être adaptées.

Mon analyse

Je trouve ce changement indispensable, même s’il arrive en retard. La pression réglementaire (loi cyber-résilience européenne) a sans doute accéléré la décision. Ce qui fait vraiment la différence, c’est que les développeurs doivent désormais consigner explicitement les paquets autorisés, créant ainsi une piste d’audit. C’est un pas significatif vers une gestion mature des risques. Soyons clairs : cela ne résout pas tout, mais c’est un progrès majeur pour la sécurité de la chaîne d’approvisionnement JavaScript.