Confiance par défaut : cela changera npm v12 pour protéger votre chaîne d'approvisionnement

GitHub a annoncé des changements importants dans npm qui arriveront avec la version 12 et sont conçus pour couper les techniques de sabotage dans la chaîne d'approvisionnement qui abusent du comportement par défaut de npm installation. En substance, ce qui vient est un changement de confiance par omission à la méfiance par omission : les scripts et les sources de dépendances qui sont maintenant exécutés ou résolus deviendront automatiquement nécessaires adoption explicite le responsable ou l'environnement de fonctionnement.

Les mesures annoncées comprennent: les scripts pré-installation, installation et post-installation ne doivent pas être exécutés automatiquement sauf approbation explicite ; que la construction de modules natifs par noeud-gyp sera soumise à la même règle ; et que les unités apportées à partir des dépôts Git ou de l'URL distante ne seront plus résolues par défaut. GitHub explique que ces modifications ferment les voies d'exécution secrètes utilisées par les attaquants, comme l'utilisation de fichiers .npmrc dans les dépendances Git pour forcer les exécutables malveillants même lorsque les scripts sont désactivés. Plus de détails techniques et l'annonce officielle sont disponibles au Le changelog GitHub.

L'impact pratique est double: d'une part, augmente significativement la résistance aux attaques de la chaîne d'approvisionnement, puisque de nombreuses campagnes récentes dépendaient de l'exécution automatique de scripts ou de dépendances non enregistrées (par exemple des incidents impliquant des paquets populaires et des vagues de paquets malveillants en npm). D'autre part, les projets et organisations qui utilisent des flux légitimes basés sur des dépendances Git, des tarbals distants ou des scripts de préparation devront revoir et adapter leur configuration avant de migrer vers npm v12, car ces flux ne fonctionneront plus par défaut.

GitHub recommande de préparer déjà la mise à jour npm 11.16.0 ou plus qui introduit des avis sur les actions qui vont rompre avec v12; cette fenêtre permet d'identifier quels paquets ou modèles du code devront être explicitement approuvés à l'avenir. Si vous voulez lire les réactions et les propositions de la communauté technique, Débat communautaire où les expériences et les solutions sont partagées.

Pour les responsables de l'équipement et de la sécurité, cela implique d'effectuer un examen pratique de la chaîne d'approvisionnement : générer ou mettre à jour le SBOM, vérifier les unités transitoires provenant de Git ou URL, et cartographier les paquets qui exécutent des scripts d'installation ou nécessitent une compilation native. Les outils et les pratiques d'analyse de tiers tels que le blocage des politiques dans l'IC, l'utilisation de fichiers de verrouillage vérifiés et le réglage des versions sont maintenant plus pertinents que jamais. Une bonne lecture contextuelle sur la nature et la portée des attaques de la chaîne d'approvisionnement est disponible dans l'article de Snyk sur le sujet: ce qui est une attaque contre la chaîne d'approvisionnement.

Du point de vue opérationnel, il convient de tester les pipelines d'IC dans un environnement qui simule les nouvelles restrictions avant la mise à jour v12. Configurer des listes blanches pour les sources nécessaires, documenter les autorisations pour les scripts et les bâtiments natifs, et automatiser l'approbation contrôlée dans les systèmes d'intégration continue évitera les surprises dans les déploiements et les sorties. Il est également temps d'envisager la possibilité de vente de dépendances critiques ou de servir des miroirs internes pour les bibliothèques utilisées dans la production, réduisant la dépendance à l'égard de sources externes dynamiques.

Nous ne devons pas perdre de vue les implications pour les petits projets open source: de nombreuses librairies ou modèles utilisent des installateurs et des scripts "préparer" pour l'emballage des tâches ou des exemples. Les responsables doivent informer leurs utilisateurs de la migration et, dans certains cas, fournir d'autres instructions (par exemple, exécuter des scripts manuellement ou adapter les processus de publication pour éviter les dépendances de Git ou de Tarbals). Le coût de la friction existe, mais est compensé par une surface d'attaque beaucoup plus faible.

Enfin, pour les organisations qui souhaitent renforcer leur position sur les nouvelles menaces, la recommandation pratique est d'élaborer un plan en deux phases : d'abord, lancer npm 11.16.0 dans tous les environnements de développement et d'IC pour recueillir des avertissements et créer une liste d'exceptions justifiées; ensuite, mettre en oeuvre des politiques automatiques d'IC qui par défaut la résolution de sources externes non approuvées et exiger un examen humain pour leur autorisation. Prendre ces mesures réduit la possibilité qu'un paquet malveillant fonctionne sans publicité pendant une installation.

Le mouvement de GitHub vers un modèle plus restrictif reflète la maturation de la défense dans les écosystèmes de masse : les outils doivent supposer que l'installation automatique est un vecteur de risque. Les équipes qui planifient à l'avance et font de ces politiques une partie de leur cycle de développement gagneront en sécurité sans sacrifier la continuité opérationnelle.