GitHub place un pare-feu entre vos runners CI et le registre npm
Le 20 octobre 2026, GitHub ouvre en préversion publique un pare-feu qui s’interpose entre les runners Actions, les agents de code et le registre npm, en inspectant les requêtes de métadonnées comme les téléchargements. Il bloque le malware au moment de l’installation, là où les scanners arrivent trop tard : activez-le si votre CI installe du code tiers.
20 octobre 2026. GitHub ouvre son package firewall en préversion publique pour tous les clients GitHub Enterprise Cloud, y compris avec résidence des données. Le service s’insère entre les terminaux — runners Actions, agents de code — et les registres de paquets en amont, et n’inspecte pour l’instant que npm. Pourquoi c’est important : les attaques par paquets ne dépendent plus de l’exécution du code applicatif, mais de l’installation elle-même. Un postinstall script peut récolter des identifiants sur un hôte de CI/CD sans qu’aucune ligne du paquet ne s’exécute vraiment — c’est cette fenêtre, le téléchargement et l’installation, que le pare-feu referme.
L’installation est devenue le moment d’exécution
Le constat de départ est daté et chiffré. GitHub décrit « un nombre croissant d’attaques par malware » qui exploitent les systèmes au moment de l’installation d’un paquet, récoltant des identifiants sur les hôtes de CI/CD ou les postes de développeur « sans même exécuter le code du paquet ». Autrement dit, l’attaquant n’a plus besoin qu’une application vulnérable charge son code : il lui suffit qu’un npm install tourne sur une machine qui détient des secrets.
Cette bascule change la géométrie des défenses. Un scanner de vulnérabilités — Dependabot, un SAST, une analyse SCA — regarde le code après le téléchargement, et souvent après la fusion. Or le mal est déjà fait au moment où l’on scrolle : le hook d’installation a tourné pendant le npm install, avant que la moindre alerte ne soit générée. C’est précisément le trou que GitHub veut combler en déplaçant la frontière de l’analyse vers le point d’installation.
Un pare-feu, pas un scanner
La différence de nature est le cœur de l’annonce. Le package firewall ne scanne pas un dépôt : il s’intercale entre le terminal et le registre, et inspecte à la fois les requêtes de métadonnées et les téléchargements de paquets à la recherche de signes d’activité malveillante. C’est un proxy d’inspection, pas un rapport rétroactif.
Le fonctionnement se décompose en trois temps. D’abord, l’administrateur définit des politiques : une période de cooldown configurable, la vérification contre la GitHub Advisory Database pour les alertes de malware ou de vulnérabilité, et des contrôles de supply chain comme la régression d’attestation (attestation downgrade). Ensuite, les terminaux — runners Actions ou agents de code — sont configurés pour faire passer leurs requêtes par le pare-feu au lieu de viser directement le registre amont. Enfin, chaque requête et chaque téléchargement est évalué contre la politique, avec un workflow d’exception similaire à celui des autres fonctionnalités GitHub Advanced Security quand un paquet est bloqué à tort.
Deux limites sont à connaître avant de s’enthousiasmer. Le service ne supporte que npm aujourd’hui — pas PyPI, pas Maven, pas les conteneurs. Et il est réservé à GitHub Enterprise Cloud ; le compte gratuit ou Team n’y a pas accès. Le service est gratuit pendant la préversion, puis sera facturé à l’usage, « similaire à la facturation Actions », au passage en disponibilité générale.
La fenêtre que le scanner ne voit pas
Pour comprendre ce que change réellement ce pare-feu, il faut regarder les cas que l’écosystème a déjà encaissés cette année. La campagne MALFEX a caché un loader de shellcode dans un addon natif npm resté en ligne — un exemple que nous avons documenté — et CrowdSec a subi une compromission de supply chain via un paquet npm détourné. Le point commun de ces incidents est le même : le paquet malveillant est téléchargé et installé avant que la communauté ne le signale, et les défenses qui reposent sur un scan post-téléchargement arrivent systématiquement en retard.
Le package firewall inverse l’ordre. En position d’inspection entre le runner et le registre, il voit la requête de métadonnées et le binaire téléchargé, au moment où ils transitent — ce qui lui permet d’interrompre l’installation avant que le postinstall ne s’exécute. C’est la première défense npm de GitHub qui opère dans le flux de l’installation plutôt que dans le cycle de revue de code.
Le cooldown configurable mérite une attention particulière. Il traduit une politique simple : refuser l’installation d’un paquet publié depuis moins de N heures, le temps que les sources de réputation et l’Advisory Database se mettent à jour. C’est une heuristique grossière, mais elle cible directement le profil dominant des attaques par typosquatting et par paquet fraîchement publié, qui vivent et meurent en quelques heures.
Où il s’insère dans la pile existante
Le package firewall ne remplace aucune brique actuelle : il s’y ajoute, à un étage précis. Dependabot continue de piloter les versions et les alertes de vulnérabilité ; l’épinglage de versions (lockfile) et les attestations SLSA ou sigstore continuent de garantir la provenance ; le pare-feu, lui, intercepte le flux d’installation. Sa valeur tient à sa position : il voit le paquet au moment où il devient exécutable, pas au moment où il est revu dans une pull request.
Cette position a un coût opérationnel qu’il faut anticiper. Faire transiter le trafic par un proxy d’inspection suppose de modifier la sortie réseau des runners et des agents — ceux-ci ne peuvent plus pointer directement vers registry.npmjs.org. Sur des runners auto-hébergés ou des agents de code distribués, c’est une question de routage et de confiance : le pare-feu devient un point de passage unique, donc un point de défaillance potentiel. Les équipes qui verrouillent déjà la sortie réseau par une allowlist devront y ajouter l’adresse du pare-feu, et prévoir sa haute disponibilité avant de l’imposer à la CI.
Ce qu’il faut faire
La marche à suivre est courte, et elle se décide en quelques minutes pour les équipes éligibles.
- Si vous êtes en Enterprise Cloud et que vos runners ou agents font du
npm install, activez le pare-feu dès maintenant — il est gratuit en préversion et le coût de configuration est faible. - Routez les terminaux par le pare-feu. La configuration ne consiste pas à cocher une case : chaque runner ou agent doit pointer vers le pare-feu au lieu du registre amont. Prévoyez la bascule sur les images de runners et les flux d’agents de code.
- Mesurez l’impact avant de verrouiller. Commencez par un mode d’observation, listez les paquets bloqués à tort, puis resserrez la politique et le cooldown.
- Ne déléguez pas tout au pare-feu. Il couvre npm, pas le reste : gardez Dependabot, la vérification des attestations et l’épinglage de versions pour les autres registres et pour la revue du code.
Vérifiez l’éligibilité de votre organisation avec un simple contrôle de plan, puis consultez la procédure de configuration.
# Un paquet fraîchement publié est le profil typique du typosquatting.
# Avec le package firewall, le cooldown bloque l'installation avant le postinstall.
npm view <paquet> time.created # âge de publication, à croiser avec votre cooldownVerdict
Si vous tournez des runners Actions ou des agents de code qui installent des paquets npm en Enterprise Cloud, activez le pare-feu aujourd’hui : c’est gratuit, et il ferme une fenêtre — l’installation — que vos scanners actuels ne couvrent pas. Si vous êtes hors Enterprise Cloud, ou si votre dépendance critique est ailleurs que dans npm, considérez-le comme un signal de direction plutôt qu’une solution : la frontière de la supply chain se déplace vers le point d’installation, et les équipes qui ne s’y préparent pas continueront de découvrir les paquets malveillants après coup.