Ing. Calogero Bono
GitHub a présenté le 20 octobre 2026 son package firewall, un filtre placé entre les ordinateurs qui installent des paquets et les registres publics d'où ceux-ci sont téléchargés. Il est aujourd'hui en aperçu public pour tous les clients de GitHub Enterprise Cloud et ne prend en charge que npm. L'objectif est d'arrêter les malwares qui frappent au moment de l'installation, un risque plus fort pour les agents IA et les systèmes de build qui installent des dépendances sans que personne ne contrôle. Si tu développes des logiciels ou si tu gères ceux qui le font, c'est un signal sur la direction que prend la sécurité de la chaîne d'approvisionnement.
Quelques termes avant d'entrer dans le vif du sujet. Un registre (ou registry) est le dépôt en ligne d'où l'on télécharge les paquets, comme npm pour JavaScript. Une dépendance est un morceau de code d'autrui que ton projet utilise. Les CI/CD sont les procédures automatiques qui compilent et publient le logiciel. Une attestation SLSA est une déclaration vérifiable sur la manière dont un paquet a été construit et par qui. Les métadonnées sont les informations sur le paquet, par exemple la liste des versions disponibles.
Qu'est-ce que le package firewall de GitHub ?
Selon le changelog officiel de GitHub, ces derniers temps une véritable vague d'attaques malveillantes exploite le moment où les paquets sont installés. Les agents et les runners de CI sont des cibles particulières, car ils installent des dépendances pour accomplir une tâche ou un build sans personne dans la boucle.
Le pare-feu se place entre les endpoints, ou les registres internes, et les dépôts de paquets en amont. Comme le rapporte The Hacker News, GitHub le décrit ainsi. «Le pare-feu inspecte à la fois les requêtes de métadonnées et les téléchargements de paquets à la recherche de signes d'activité malveillante, en agissant comme une porte de politique appliquée au moment de l'installation», c'est-à-dire un portail de règles appliqué au moment de l'installation.
Le sujet n'est pas théorique. Le site The Register a titré sur une campagne dans laquelle les attaquants auraient transformé les issues de GitHub en attaque contre la chaîne d'approvisionnement, visant 61 dépôts publics en moins d'une heure. D'après la page dont nous disposons, aucun autre détail n'apparaît, donc nous ne pouvons pas dire si les deux informations sont liées et de quelle façon.
Comment fonctionne-t-il et quels contrôles propose-t-il ?
Le fonctionnement se déroule en deux étapes. D'abord les administrateurs définissent les règles pour leur enterprise. Ensuite les agents de codage et les hôtes CI/CD pointent vers le pare-feu au lieu de viser directement les registres publics. Les requêtes de métadonnées comme les téléchargements passent par le pare-feu, qui les évalue selon la politique définie.
Les contrôles disponibles
D'après la liste de The Hacker News, les contrôles suivants sont disponibles.
- Blocage des malwares connus, en contrôlant les alertes actives dans la GitHub Advisory Database.
- Blocage selon la gravité des vulnérabilités, toujours via cette base. Le réglage par défaut ne bloque que le niveau «Critical only», mais on peut choisir «High or higher», «Medium or higher» ou «Any severity».
- Blocage des rétrogradations d'attestation. Le pare-feu compare les attestations de la version demandée avec celles des versions précédentes et stoppe le téléchargement si l'attestation SLSA manque.
- Blocage des nouveaux scripts d'installation, c'est-à-dire ceux qui s'exécutent avec les hooks preinstall ou postinstall et qui peuvent servir à voler des données sensibles.
- Période d'attente (cooldown), qui empêche d'installer les versions plus récentes que l'âge minimal configuré.
Le cooldown peut aller de 1 à 365 jours. La valeur par défaut est de 1 jour et il se désactive en le réglant sur 0.
Et si un bon paquet est bloqué ?
Si un paquet est bloqué par erreur, l'utilisateur peut demander une exception. Pour GitHub, le flux est proche de celui d'autres fonctions de GitHub Advanced Security. Selon The Hacker News, la demande peut être approuvée par les administrateurs et les responsables de la sécurité de l'enterprise.
Combien coûte-t-il et qui peut l'utiliser ?
Le service est disponible en aperçu public pour tous les clients GitHub Enterprise Cloud, y compris la version avec résidence des données. Pendant l'aperçu, il est gratuit. Lorsque la disponibilité générale arrivera, GitHub annonce qu'il sera payant selon la consommation mesurée, de façon similaire à la facturation d'Actions.
GitHub explique que l'aperçu sert à faire grandir l'infrastructure et à ajouter des fonctions en fonction des demandes des clients. Pour la configuration, l'entreprise renvoie à la documentation «Protéger les endpoints avec le package firewall».
Pourquoi parle-t-on tant de périodes d'attente ?
Le cooldown est la règle la plus simple et sans doute la plus répandue. The Hacker News rappelle que, dans la dernière année, des attentes similaires ont été introduites dans npm, Python, Visual Studio Code, Ruby, Bun, pnpm et Yarn. Le principe est de réduire la probabilité qu'une version fraîchement publiée et jamais relue finisse tout de suite dans un build.
Il aide surtout contre celui qui prend le contrôle du compte d'un mainteneur et publie une version empoisonnée d'un paquet populaire. L'attente freine la diffusion rapide, qu'elle soit manuelle ou automatique.
Le même article signale que Rust 1.100, attendu le 12 novembre 2026, devrait ajouter un âge minimal de publication configurable pour les crates. L'option s'appelle «global-min-publish-age» et se trouve dans le fichier cargo/config.toml. Si elle n'est pas précisée, une attente par défaut de sept jours s'applique.
Côté revers de la médaille, s'exprime Socket, citée par The Hacker News. «Le compromis est que les correctifs légitimes doivent eux aussi attendre, sauf si les développeurs font une exception», affirme la société. Elle ajoute qu'une version passée au travers des contrôles peut tout simplement survivre au cooldown. La valeur, selon Socket, est de donner du temps aux chercheurs, aux mainteneurs et aux registres pour intervenir.
Limites à connaître
- Aujourd'hui le pare-feu ne prend en charge que npm. Ceux qui travaillent avec PHP, Python ou d'autres écosystèmes ne sont pas couverts, et les sources n'indiquent aucune date pour les autres registres.
- Il est réservé aux clients GitHub Enterprise Cloud. Les sources ne parlent pas de formules moins chères.
- Nous sommes en aperçu. Fonctions, infrastructure et tarifs peuvent changer, et le coût à la consommation n'est pas encore chiffré.
- Nous n'avons pas de données indépendantes sur l'efficacité. Les sources rapportent les déclarations de GitHub, pas des tests sur de vrais malwares, et aucun chiffre sur les faux positifs n'est donné.
- Comme le rappelle Socket, le cooldown ne rend pas le code malveillant inoffensif. Une version non détectée peut rester cachée au-delà de l'attente.
Ce qui change pour ceux qui travaillent avec le numérique
Le point pratique est que la sécurité passe du contrôle a posteriori au contrôle avant l'installation. Pour ceux qui développent avec des agents IA qui écrivent et installent seuls, cela signifie disposer d'une règle centrale au lieu de faire confiance à chaque agent. Si tu utilises des outils de développement guidés par l'IA, il est utile de relire les risques que nous avons décrits dans notre article sur le vibe coding pour la PME.
Pour les entreprises italiennes, le sujet touche aussi à la conformité. La chaîne d'approvisionnement logiciel fait partie de ce que nous traitons dans le guide sur le registre des fournisseurs NIS2. Pouvoir prouver que les paquets passent par un filtre aux règles écrites est un argument concret, même si aucune source ne relie le pare-feu à la NIS2.
Ceux qui utilisent beaucoup d'open source devraient se rappeler que chaque dépendance est un fournisseur. Nous en parlons dans l'approfondissement sur l'open source en entreprise. Même ceux qui ne sont pas clients Enterprise peuvent reprendre l'idée avec les outils déjà disponibles, par exemple les périodes d'attente que proposent certains gestionnaires de paquets.
Pour les serveurs de build et de production, comptent aussi les mises à jour et l'isolement. Si tu veux une infrastructure gérée par d'autres, il existe notre service d'hébergement et serveurs gérés. Si tu évalues plutôt un projet sur mesure, le parcours se trouve dans le développement de logiciels sur mesure.
Notre avis
L'idée est bonne. Arrêter un paquet avant qu'il ne tourne sur l'ordinateur est plus efficace que s'en apercevoir après, et le faire en un point unique évite de dépendre de la discipline de chaque développeur ou de chaque agent. Le fait que GitHub parte précisément des agents sans supervision nous semble une lecture honnête du problème.
Les réserves sont au nombre de deux. La première est commerciale. Une protection aussi utile, pour l'instant réservée à la gamme Enterprise et payante à la consommation après l'aperçu, risque de laisser de côté les petites équipes, qui sont souvent les plus exposées. La seconde est technique. Plusieurs contrôles reposent sur la base de données de GitHub et sur le temps, et le temps n'est pas une garantie, comme le reconnaît Socket elle-même.
Nous ne le considérons donc pas comme un bouclier définitif. C'est une couche de plus, utile si elle s'accompagne d'une revue des dépendances, du blocage des versions et de permissions minimales pour les agents. Si tu penses qu'il suffit d'activer le pare-feu, tu te donnes une fausse sécurité.
Questions fréquentes
Le package firewall de GitHub est-il gratuit ?
Oui, mais seulement pendant l'aperçu. GitHub annonce qu'à la disponibilité générale il sera facturé selon la consommation mesurée, de façon similaire à Actions. Les tarifs ne sont pas encore communiqués.
Ne fonctionne-t-il qu'avec npm ?
Oui, pour l'instant il ne prend en charge que les paquets npm. Les sources n'annoncent aucune date pour d'autres écosystèmes. Si tu utilises d'autres langages, il faut pour le moment chercher d'autres défenses.
Qui peut l'utiliser ?
Tous les clients GitHub Enterprise Cloud, y compris la version avec résidence des données. Les sources ne mentionnent pas d'autres formules. Les administrateurs configurent les règles pour l'ensemble de l'enterprise.
Que se passe-t-il s'il bloque un paquet légitime ?
L'utilisateur peut demander une exception. Selon The Hacker News, la demande peut être approuvée par les administrateurs et les responsables de la sécurité. Le flux, indique GitHub, est proche de celui d'autres fonctions d'Advanced Security.
La période d'attente suffit-elle à arrêter les malwares ?
Non. Elle fait gagner du temps face aux versions fraîchement publiées, mais Socket rappelle que le code malveillant ne devient pas inoffensif avec le temps. Une version non détectée peut dépasser l'attente.
Ce qu'il faut suivre jusqu'à la disponibilité générale
Dans les prochains mois, il convient de suivre trois éléments. Le prix à la consommation que GitHub fixera, l'éventuelle extension au-delà de npm et l'arrivée de l'attente minimale dans Rust 1.100, prévue le 12 novembre 2026. En attendant, tu peux agir ainsi.
- Liste les dépendances utilisées par la CI et par les agents, et décide qui peut installer quoi sans supervision.
- Évalue une période d'attente sur les nouvelles versions, en sachant qu'elle retarde aussi les correctifs légitimes.
- Prépare une procédure pour les exceptions, avec un responsable qui approuve vite mais avec une trace écrite.
