Le 17 juin 2026, un mainteneur npm compromis publie mastra@1.13.1 depuis une adresse Tutamail anonyme, en dehors du pipeline GitHub Actions habituel. Le seul changement : une dépendance ajoutée, easy-day-js, un typosquat de la bibliothèque dayjs. Résultat : 140 packages de l’écosystème @mastra touchés, un script postinstall qui désactive la vérification TLS, télécharge une charge de second niveau et installe une persistance sur Windows, macOS et Linux. Microsoft attribue l’attaque à Sapphire Sleet, un groupe nord-coréen, avec un niveau de confiance élevé.
C’est ce genre de scénario que GitHub Package Firewall, passé en preview publique le 20 octobre 2026, essaie d’intercepter avant qu’il n’atteigne tes runners. Pas en analysant le code après coup, mais en se plaçant entre tes endpoints et le registre npm, au moment même où le `npm install` part chercher ses dépendances.
Ce que fait réellement le pare-feu
Le principe est simple sur le papier. Tu configures tes runners Actions, tes postes de développement ou tes agents de code pour router leurs requêtes npm — métadonnées de package comme téléchargements effectifs — à travers le pare-feu plutôt que directement vers la registry publique. Chaque requête est alors évaluée contre une politique que tu définis au niveau de l’organisation : une période de cooldown qui bloque les versions trop récentes (le temps que la communauté détecte une éventuelle charge malveillante), une vérification croisée avec la GitHub Advisory Database, et des contrôles de chaîne d’approvisionnement comme la détection d’une attestation de provenance qui régresse entre deux versions.
Si un package légitime se retrouve bloqué par erreur, tu peux demander une exception via un workflow similaire à celui des autres fonctionnalités GitHub Advanced Security — pas de blocage définitif sans recours.
Ce qui manque encore
Deux limites à garder en tête avant de t’enthousiasmer. D’abord, seul l’écosystème npm est couvert pour l’instant — rien pour PyPI, NuGet ou les modules Terraform, alors que les attaques par typosquat touchent tous les registries. Ensuite, et c’est le point le plus important : le pare-feu ne protège que le trafic qui passe réellement par lui. Un runner mal configuré, un script qui pointe en dur vers registry.npmjs.org, ou un développeur qui installe en local sans passer par le proxy d’entreprise, contournent entièrement la protection. Ce n’est pas un défaut caché, GitHub le dit explicitement dans sa documentation : la fonctionnalité dépend de l’endpoint qui joue le jeu.
Disponible pour tous les clients GitHub Enterprise Cloud (y compris avec data residency), gratuit pendant la preview, facturé à l’usage comme Actions à la disponibilité générale — sans date ni tarif annoncés pour l’instant.
Pourquoi ça a du sens maintenant
Le cas Mastra n’est pas isolé. TanStack, Jscrambler, et une bonne partie du calendrier 2026 des compromissions npm suivent le même schéma, déjà détaillé dans notre tour d’horizon des attaques supply chain CI/CD de 2026 : un compte mainteneur pris, un typosquat ou une dépendance ajoutée discrètement, un hook postinstall qui exfiltre des tokens avant même que le code applicatif ne tourne. C’est exactement le moment où un pare-feu en amont du téléchargement a le plus de valeur — contrairement à un scan de code qui arrive après coup, quand le malware a déjà eu l’occasion de s’exécuter.
Ça rejoint la logique derrière les workflow lockfiles GitHub Actions, publiés quatre jours plus tôt : les deux mécanismes attaquent le même problème — une chaîne de dépendances qui change sous tes pieds sans que tu t’en rendes compte — mais à des niveaux différents. Les lockfiles verrouillent le graphe de dépendances de tes workflows Actions eux-mêmes ; le pare-feu filtre ce que npm va chercher pendant l’exécution de ton build. Les deux ensemble, pas l’un à la place de l’autre.
En attendant que le pare-feu couvre d’autres écosystèmes, la mitigation la plus simple reste à la portée de tout le monde dès aujourd’hui : npm install --ignore-scripts désactive l’exécution de tout hook postinstall, au prix de devoir parfois relancer manuellement un build natif pour les packages qui en ont réellement besoin.
# Installer sans exécuter les scripts de cycle de vie
npm install --ignore-scripts
# Vérifier après coup si une dépendance a tenté d'en profiter
npm config get ignore-scriptsFAQ
Le pare-feu remplace-t-il un scanner de dépendances type Dependabot ou Snyk ?
Non. Dependabot et les scanners SCA analysent ton code et tes manifestes de dépendances pour repérer des vulnérabilités connues. Le pare-feu, lui, agit en amont, au moment où npm va chercher un package sur le réseau — il bloque avant le téléchargement, pas après coup sur une base déjà installée.
Faut-il GitHub Enterprise pour en profiter ?
Oui, c’est réservé aux clients GitHub Enterprise Cloud à ce stade (data residency incluse). Rien n’indique pour l’instant une disponibilité sur les plans Team ou Pro.
Si je n’ai pas Enterprise, que faire en attendant ?
Verrouille tes dépendances avec un fichier de lock à jour, désactive les scripts de cycle de vie par défaut sur les environnements CI qui n’en ont pas besoin, et surveille les alertes de la GitHub Advisory Database sur tes dépôts — c’est la même base que le pare-feu interroge en coulisses.
Pour la suite
Le pare-feu npm est un bon réflexe défense-en-profondeur, pas une solution miracle : il ne vaut que ce que vaut le routage réseau derrière lui. Si tu es sur GitHub Enterprise, active-le en mode non bloquant d’abord pour calibrer la politique de cooldown sans casser tes builds, puis passe en application stricte une fois que tu as confiance dans les faux positifs. Et quel que soit ton plan GitHub, prends cinq minutes pour vérifier que tes pipelines n’installent pas déjà des dépendances avec des scripts de cycle de vie que tu n’as jamais auditées.
Laisser un commentaire