La sécurité de la chaîne d'approvisionnement logicielle est devenue une préoccupation primordiale pour les professionnels de la sécurité informatique, le gestionnaire de packages **npm** étant une cible fréquente. **GitHub**, le gardien de **npm**, prend des mesures décisives pour atténuer ces risques en introduisant des 'changements majeurs' dans la prochaine version 12 de **npm**.  ### Désactivation des Scripts d'Installation par Défaut Le cœur de la mise à jour réside dans la désactivation par défaut des scripts d'installation. Ce changement combat directement les techniques d'attaque qui exploitent la commande `npm install` pour déclencher l'exécution de code malveillant via les hooks de cycle de vie de **npm**. **GitHub** a identifié les scripts de cycle de vie au moment de l'installation comme la "plus grande surface d'exécution de code dans l'écosystème **npm**". Actuellement, `npm install` exécute des scripts provenant de chaque dépendance transitive, ce qui signifie qu'un seul package compromis, où qu'il se trouve dans l'arbre des dépendances, peut exécuter du code arbitraire sur la machine d'un développeur ou sur un CI runner. En bloquant ces comportements, **npm** exigera désormais une approbation explicite de l'utilisateur avant que l'exécution du code ne soit initiée automatiquement lors de l'installation. ### Changements Clés dans npm v12 Les changements à venir sont complets et ciblent plusieurs vecteurs d'attaque courants : * `npm install` n'exécutera plus les scripts `preinstall`, `install`, ou `postinstall` des dépendances, sauf s'ils sont explicitement autorisés dans le projet. * `npm install` ne résoudra plus les dépendances **Git**, qu'elles soient directes ou transitives, sauf si elles sont explicitement autorisées via `--allow-git`. * `npm install` ne résoudra plus les dépendances à partir d'URL distantes, comme les tarballs `https`, sauf si elles sont explicitement autorisées via `--allow-remote`. Cela s'étend également aux builds natifs `node-gyp`, où un package avec un fichier `binding.gyp` mais sans script d'installation explicite sera toujours bloqué, car **npm** en exécute implicitement un `node-gyp rebuild` pour celui-ci. De même, les scripts `prepare` provenant de dépendances **Git**, de fichiers et de liens seront bloqués. ### Atténuation des Exploits de Dépendances Git En définissant `--allow-git` sur `none` par défaut, **GitHub** ferme un chemin d'exécution de code crucial où un fichier de configuration `.npmrc` d'une dépendance **Git** pouvait outrepasser l'exécutable **Git**. Cette vulnérabilité existait même avec le drapeau `--ignore-scripts`, conçu pour empêcher les packages d'exécuter automatiquement les scripts de cycle de vie intégrés lors de l'installation. ### Préparation des Développeurs et Bonnes Pratiques **GitHub** recommande aux développeurs de se préparer à ces changements en passant à **npm** 11.16.0 ou une version plus récente. Après la mise à niveau, les développeurs devraient effectuer une installation normale et examiner tous les avertissements affichés. Le flux de travail conseillé est d'utiliser `npm approve-scripts --allow-scripts-pending` pour identifier les packages avec des scripts, approuver ceux qui sont fiables, puis committer le `package.json` mis à jour. Seuls les scripts explicitement approuvés continueront de s'exécuter après la mise à niveau, tandis que les scripts non approuvés seront bloqués. Ce passage d'une confiance implicite à une approbation explicite améliore considérablement la posture de sécurité de l'écosystème **npm**. Plus tôt cette année, **npm** a également introduit `min-release-age`, un paramètre conçu pour rejeter toute version de package publiée moins de X jours après sa publication. Cela agit comme une sauvegarde supplémentaire contre les packages malveillants nouvellement publiés, renforçant ainsi la chaîne d'approvisionnement logicielle.