# GitHub lance son Package Firewall en préversion pour Enterprise Cloud

> GitHub a ouvert la préversion de son Package Firewall pour bloquer les scripts malveillants à l'installation. Réservé à GHEC, il gère uniquement npm.

- URL: https://roobrief.com/fr/posts/github-package-firewall
- Language: fr
- Published: 2026-10-22T01:00:00.000Z
- Tags: dev
- Source: https://github.blog/changelog/2026-10-20-github-package-firewall-in-public-preview/

**GitHub a lancé la préversion publique de son Package Firewall pour bloquer les logiciels malveillants dès l'installation des dépendances, mais la fonction est réservée à GitHub Enterprise Cloud et ne prend en charge que npm.**

GitHub a annoncé le 20 oct. 2026 sur son blog l'ouverture de la préversion publique de son pare-feu de paquets (Package Firewall). Ce module d'inspection en ligne vise à neutraliser les scripts malveillants exécutés lorsque des postes de développement, des exécuteurs CI ou des agents de codage installent des dépendances logicielles. L'accès est ouvert à l'ensemble des organisations abonnées à GitHub Enterprise Cloud (GHEC), y compris celles avec résidence locale des données.

## Qui peut en profiter et quelle est la tarification

Le pare-feu de paquets n'est pas disponible pour tous les utilisateurs. Il reste exclusif aux organisations sous GitHub Enterprise Cloud. Les comptes individuels (Free et Pro) ainsi que les forfaits GitHub Team en sont exclus.

| Forfait | Prise en charge du pare-feu | Tarif pendant la préversion | Tarif à la disponibilité générale (GA) | Écosystèmes gérés |
|---|---|---|---|---|
| GitHub Free / Team | Non | Sans objet | Sans objet | Sans objet |
| GitHub Enterprise Cloud (GHEC) | Oui (résidence des données comprise) | Gratuit | Facturation à l'usage (prévue) | npm (uniquement) |

Pendant la phase de préversion publique, l'outil est accessible sans coût supplémentaire. GitHub a précisé qu'une fois la disponibilité générale (GA) atteinte, le service adoptera un modèle facturé à l'usage, similaire à la tarification de GitHub Actions. Les tarifs unitaires et le calendrier de sortie définitive n'ont pas encore été communiqués.

## Ce que le pare-feu inspecte et ses limites actuelles

Les approches classiques de sécurité de la chaîne logicielle interviennent souvent après le commit, via des analyses de dépôts ou des alertes de vulnérabilités. Or, de plus en plus d'attaques ciblent le moment précis de l'installation des paquets (par exemple via des scripts `preinstall`) pour dérober des jetons d'accès ou des variables d'environnement avant même l'exécution du code principal. Les agents de codage autonomes et les exécuteurs CI y sont particulièrement exposés, car ils installent fréquemment des dépendances sans intervention humaine directe.

Le Package Firewall s'intercale entre les postes de travail et le registre public officiel (`registry.npmjs.org`). Il inspecte en direct les métadonnées et le téléchargement des archives (fichiers tarball). Les équipes d'administration peuvent appliquer quatre règles fondamentales :

1. **Blocage des logiciels malveillants connus** : rejet immédiat des paquets répertoriés dans la base GitHub Advisory Database.
2. **Filtrage des avis de vulnérabilité** : blocage des versions concernées par des failles signalées dépassant un seuil de gravité défini (Critique ou Élevé).
3. **Interdiction des régressions d'attestation** : si une version antérieure comportait une attestation cryptographique de provenance (preuve d'une chaîne de compilation vérifiée) et que la nouvelle version demandée en est dépourvue, la mise à jour est signalée comme potentiellement compromise et bloquée.
4. **Période de temporisation (cooldown)** : rétention temporaire des versions de paquets fraîchement publiées pour laisser à la communauté open source le temps d'identifier et de signaler tout comportement suspect.

La restriction majeure à ce jour concerne le périmètre : **le pare-feu ne prend en charge que les paquets npm**. Les autres écosystèmes majeurs tels que PyPI (Python), Maven (Java) ou Cargo (Rust) ne peuvent pas transiter par ce filtre pour le moment.

## Déploiement et pièges du flux d'exception

Pour activer la protection, l'équipe d'administration configure la politique globale dans les paramètres de l'entreprise, puis réoriente le registre des gestionnaires de paquets (`.npmrc`) des machines et des exécuteurs CI vers l'URL du pare-feu.

Si un paquet interne légitime ou une version urgente se retrouve bloqué par erreur (faux positif), la console ou les journaux CI génèrent un lien direct vers un formulaire de dérogation. Les équipes de développement peuvent y soumettre une justification, qui sera ensuite examinée et validée par les responsables de la sécurité via un flux similaire à celui de GitHub Advanced Security (GHAS).

Dans les environnements exploitant des agents autonomes exécutant de nombreuses tâches en parallèle, un faux positif peut toutefois bloquer toute une chaîne d'intégration jusqu'à l'intervention manuelle d'une personne habilitée. Une période de temporisation trop longue risque également de ralentir les montées de version courantes. Il est donc recommandé d'adopter des délais courts au démarrage et d'identifier clairement les personnes chargées d'approuver les dérogations.

## Ce qu'il faut surveiller

GitHub a indiqué vouloir faire évoluer son infrastructure en fonction des retours clients avant d'ajouter de nouvelles fonctionnalités. L'élargissement à d'autres écosystèmes comme PyPI et le coût réel de la tarification à l'usage sur les budgets d'intégration continue constitueront les principaux points à suivre lors du passage en disponibilité générale.

## Sources

- [GitHub package firewall in public preview](https://github.blog/changelog/2026-10-20-github-package-firewall-in-public-preview/) (The GitHub Blog)
- [Protecting endpoints with package firewall](https://docs.github.com/en/enterprise-cloud@latest/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/protecting-endpoints-with-package-firewall) (GitHub Docs)