Sécuriser sa supply chain logicielle en 2026 : GitHub et npm changent les règles

Une supply chain logicielle ne se limite pas au code que vous écrivez. Elle inclut les dépendances téléchargées, les scripts exécutés pendant l’installation, les actions GitHub utilisées par la CI, les jetons de publication et les outils qui mettent automatiquement les paquets à jour. En 2026, GitHub et npm ont renforcé plusieurs de ces maillons pour ralentir la propagation d’un paquet compromis et réduire l’intérêt du vol de secrets.

Pourquoi ces changements maintenant ?

Les campagnes récentes montrent un schéma récurrent : compromettre un mainteneur ou un workflow, récupérer des identifiants, publier une version malveillante puis profiter de l’automatisation des mises à jour pour la diffuser rapidement. La défense ne consiste donc plus seulement à analyser le code final : il faut aussi réduire ce qui s’exécute automatiquement et limiter la durée de vie des secrets capables de publier.

1. npm v12 n’exécute plus les scripts d’installation des dépendances par défaut

npm v12 est disponible depuis juillet 2026. Son changement le plus visible est que les scripts de cycle de vie des dépendances — notamment preinstall, install et postinstall — ne sont plus exécutés automatiquement. Les builds natifs implicites via node-gyp sont concernés eux aussi.

L’objectif est simple : empêcher qu’une dépendance nouvellement installée puisse immédiatement exécuter du code sur la machine du développeur ou dans la CI. Les projets qui utilisent légitimement ces scripts doivent désormais approuver explicitement les paquets concernés.

2. Les dépendances Git et URL distantes deviennent elles aussi explicites

npm v12 désactive également par défaut la résolution des dépendances provenant directement d’un dépôt Git ou d’une URL distante. Ces sources peuvent être légitimes, mais elles contournent une partie des contrôles habituels d’un registre et ouvrent des chemins supplémentaires d’exécution de code.

Si votre package.json contient une dépendance GitHub, Git ou un tarball distant, vérifiez si elle est réellement nécessaire. Lorsqu’un paquet officiel existe sur le registre npm, il est généralement plus simple à auditer et à verrouiller.

3. Dependabot attend désormais trois jours pour les mises à jour de version

Depuis juillet, Dependabot applique par défaut un délai de trois jours avant de proposer une nouvelle version d’une dépendance. Ce délai concerne les mises à jour de version classiques, pas les mises à jour de sécurité.

L’idée est de ne plus être le premier projet à adopter automatiquement une release tout juste publiée. Si une version est compromise ou cassée, quelques heures ou quelques jours supplémentaires laissent le temps aux mainteneurs, chercheurs et utilisateurs de faire remonter des signaux avant qu’elle n’arrive dans votre dépôt.

4. GitHub Actions ajoute des protections d’exécution autour des workflows sensibles

Les workflows déclenchés par des contributions externes restent une cible importante. Le déclencheur pull_request_target est particulièrement sensible parce qu’il s’exécute dans le contexte du dépôt cible, où des permissions ou secrets peuvent être disponibles. GitHub avait déjà durci les comportements de checkout pour éviter qu’un workflow sensible récupère automatiquement du code non fiable provenant d’un fork.

Depuis le 17 septembre 2026, les protections d’exécution GitHub Actions sont disponibles de façon générale. Elles permettent de définir qui peut déclencher un workflow, quels événements sont autorisés et, si nécessaire, de cibler des fichiers de workflow précis. Un mode d’évaluation permet d’observer ce qui serait bloqué avant d’appliquer réellement la politique, et les résultats sont visibles dans les Insights et accessibles par API.

Pour les dépôts publics qui n’ont pas de politique d’événements applicable, GitHub prépare aussi une protection par défaut qui désactive pull_request_target. Cette règle arrive d’abord en mode évaluation ; GitHub indique une mise en application à partir du 2 novembre 2026 pour les dépôts concernés qui utilisaient encore la politique par défaut avant la disponibilité générale.

Depuis le 10 septembre, le nouveau réglage cache-mode permet aussi de limiter l’accès au cache Actions. Pour les événements à faible niveau de confiance comme pull_request_target, le mode par défaut est en lecture seule, ce qui réduit la possibilité d’empoisonner un cache qui serait ensuite réutilisé par un workflow plus privilégié.

La règle d’architecture reste néanmoins la même : un workflow disposant de secrets ou de droits d’écriture ne doit pas exécuter du code contrôlé par une pull request externe sans isolation, validation explicite et permissions minimales.

5. Publier sur npm sans jeton longue durée devient plus réaliste

npm développe le trusted publishing basé sur OIDC : le registre vérifie l’identité du workflow GitHub Actions au moment de la publication, au lieu de demander un jeton npm permanent stocké comme secret. Depuis septembre 2026, un même paquet peut disposer de plusieurs configurations de trusted publishing, par exemple pour séparer stable, préversion et staging.

npm propose également la publication par étapes. Une version peut être mise en attente d’une approbation supplémentaire et le contrôle antimalware doit être terminé avant validation. Cela ajoute une barrière même si des identifiants de CI sont compromis.

Checklist : quoi vérifier dans un dépôt aujourd’hui ?

• connaître la version de npm réellement utilisée en local et dans la CI ;
• inventorier les dépendances qui exécutent des scripts d’installation ;
• chercher les dépendances Git ou URL distantes dans les manifests ;
• vérifier les workflows utilisant pull_request_target ou des secrets sur des contributions externes ;
• examiner les protections d’exécution GitHub Actions et utiliser le mode d’évaluation avant blocage ;
• contrôler cache-mode sur les workflows à faible niveau de confiance ;
• réduire les permissions GITHUB_TOKEN au strict nécessaire ;
• garder Dependabot activé et comprendre le délai de trois jours pour les mises à jour de version ;
• préférer OIDC / trusted publishing aux jetons npm longue durée quand le workflow le permet ;
• verrouiller les versions des dépendances et relire les changements avant fusion automatique.

Le changement important : moins d’automatisme implicite

Le point commun de ces évolutions est la réduction des actions exécutées automatiquement : une dépendance ne lance plus forcément son script d’installation, une nouvelle release n’arrive plus immédiatement via Dependabot et une publication peut demander une identité de workflow ou une validation supplémentaire.

Ces garde-fous ne remplacent pas les revues de code, le verrouillage des dépendances ni une CI bien configurée. Mais ils réduisent la vitesse à laquelle une compromission isolée peut devenir un incident de chaîne d’approvisionnement.

Sources

• GitHub — Disrupting supply chain attacks on npm and GitHub Actions
• GitHub Changelog — npm v12 et sécurité à l’installation
• GitHub Changelog — délai par défaut de Dependabot
• GitHub Changelog — plusieurs configurations trusted publishing npm
• GitHub Changelog — protections d’exécution GitHub Actions
• GitHub Changelog — contrôle du cache Actions avec cache-mode

Publié le 9 septembre 2026. Mis à jour le 18 septembre 2026 avec les protections d’exécution GitHub Actions et cache-mode.