GitHub déploie un pare-feu npm face à une campagne d’empoisonnement de la chaîne d’approvisionnement

GitHub a annoncé le 29 octobre la mise en préversion publique d’un pare-feu pour les paquets npm, conçu pour bloquer l’installation de dépendances malveillantes dès leur téléchargement. Cette annonce intervient au moment où des chercheurs en sécurité révèlent une campagne d’attaque massive ayant ciblé 61 dépôts publics sur la plateforme, exploitant le système de suivi des incidents (GitHub Issues) pour injecter du code malveillant dans les pipelines d’intégration continue.

Des chercheurs de Radware ont identifié au moins 83 attaques distinctes menées contre 61 dépôts publics entre le 1er et le 3 septembre 2026. Parmi les cibles figurent des projets largement utilisés tels que Google LangExtract, Trivy, le navigateur Brave et MLflow. La quasi-totalité des charges malveillantes, 77 sur 83, ont été publiées dans un intervalle de 43 minutes, suggérant une opération coordonnée et automatisée.

Le vecteur d’attaque exploite une fonctionnalité légitime de GitHub Actions : l’exécution automatique de workflows déclenchée par l’ouverture ou la modification d’un ticket (Issue). Les assaillants créent des tickets contenant des charges utiles conçues pour être interprétées par les workflows CI/CD vulnérables. Lorsque le workflow s’exécute, il télécharge et exécute du code arbitraire, permettant le vol de jetons d’accès, de clés API et d’autres secrets stockés dans l’environnement de construction.

Selon Gabi Nakibly, vice-président de Radware, l’objectif final serait une attaque en chaîne d’approvisionnement classique : une fois en possession de credentials valides pour un dépôt, l’attaquant peut modifier le code source et propager la compromission aux utilisateurs en aval.

Le pare-feu présenté par GitHub se positionne entre les points de terminaison (agents de codage IA, runners CI/CD, postes de développeurs) et les registres de paquets publics. Il inspecte à la fois les requêtes de métadonnées et les téléchargements de paquets pour détecter les signaux d’activité malveillante, agissant comme une « porte de politique » au moment de l’installation.

Les administrateurs peuvent configurer plusieurs contrôles : blocage des paquets référencés dans la base de données d’avis GitHub pour logiciels malveillants actifs ; blocage selon la gravité des vulnérabilités (par défaut « Critique uniquement ») ; blocage des dégradations d’attestation SLSA ; blocage des scripts d’installation récemment ajoutés (hooks preinstall/postinstall) ; et période de « refroidissement » empêchant l’installation de versions trop récentes.

Cette approche répond à une évolution majeure : les agents d’IA et les systèmes d’automatisation installent désormais des dépendances sans intervention humaine explicite, augmentant considérablement la surface d’exposition aux paquets compromis.

La campagne observée par Radware illustre l’industrialisation des attaques sur la chaîne d’approvisionnement. L’automatisation permet de cibler des dizaines de projets en quelques minutes, exploitant la confiance accordée aux workflows CI/CD et la prolifération des secrets dans les environnements de construction.

Le pare-feu npm de GitHub, bien qu’en préversion et limité à l’écosystème JavaScript/TypeScript pour l’instant, marque une évolution vers une sécurité déplacée vers la gauche (shift-left) : non plus seulement dans le code, mais au moment même où la dépendance est récupérée. Son efficacité dépendra de l’adoption par les organisations et de la richesse des politiques configurées.

Sources : The Hacker News, The Register