GitHub Package Firewall opens public preview, blocking malicious npm packages
GitHub is opening Package Firewall as a public preview to Enterprise Cloud customers, checking package queries and downloads against centralized security policies; currently only npm packages are supported. Administrators can set a waiting period after a new version is released, block based on malware and vulnerability information from the GitHub Advisory Database, and prevent downloads when install scripts such as preinstall or postinstall appear for the first time in a new version or when SLSA provenance that previous versions had is missing. The firewall sits between clients and upstream package sources, so coding agents and CI/CD hosts must route their requests through the service for it to take effect; it is free during the preview, and general availability will be billed by usage. GitHub has not announced the general availability date or specific pricing.
Why read this
AI score 62
GitHub has turned the interception rules at the package installation stage into a configurable service, which readers can use to understand protection approaches against supply chain attacks in CI and coding agent scenarios.
Topics
Body
GitHub hat seine Package Firewall als öffentliche Vorschau für Enterprise-Cloud-Kunden freigegeben. Der Dienst prüft Paketabfragen und Downloads anhand zentraler Sicherheitsrichtlinien. Vorerst unterstützt er ausschließlich npm-Pakete.
Weiterlesen nach der Anzeige
Mit der Firewall reagiert GitHub auf Angriffe, die Schadcode während der Paketinstallation ausführen. Besonders gefährdet seien Coding-Agenten und CI-Runner, die Abhängigkeiten ohne menschliche Kontrolle installieren. Laut GitHubs Vorstellung der Package Firewall steht die Vorschau auch Kunden offen, die GitHub Enterprise Cloud mit Datenresidenz nutzen, also mit Datenspeicherung in einer gewählten Region.
Mindestalter und Sicherheitsmeldungen als Filter
In einem ersten Schritt legen Administratoren die Regeln für ihr Unternehmen fest. Dazu gehört eine konfigurierbare Wartefrist für neu veröffentlichte Paketversionen: Erst nach deren Ablauf lässt die Firewall die Installation zu. Außerdem kann sie Pakete anhand von Malware- und Schwachstellenmeldungen in der GitHub Advisory Database prüfen und sperren. Ein weiterer Filter schlägt an, wenn eine neue Paketversion erstmals Installationsskripte wie preinstall oder postinstall enthält. Da solche Skripte beliebigen Code ausführen können, blockiert die Firewall bei aktiviertem Filter den Download.
Eine weitere Kontrolle erkennt sogenannte Attestation-Downgrades. Dabei vergleicht die Firewall die Herkunftsnachweise einer angeforderten Paketversion mit denen früherer Versionen. Hatte ein Paket zuvor SLSA-Attestierungen, die bei der neuen Version fehlen, blockiert sie den Download. Solche fehlenden Nachweise können auf einen kompromittierten Veröffentlichungsprozess hindeuten, erklärt GitHub in der Dokumentation zur Einrichtung der Package Firewall.
Paketzugriffe müssen durch die Firewall laufen
Die Firewall sitzt zwischen den Clients beziehungsweise internen Registries und den vorgelagerten Paketquellen. Damit die Regeln greifen, müssen etwa Coding-Agenten und CI/CD-Hosts ihre Anfragen über den Dienst schicken, statt direkt auf die öffentlichen Registries zuzugreifen. GitHub prüft dabei sowohl Metadatenabfragen zu Paketlisten als auch die eigentlichen Downloads. Bei einer irrtümlichen Sperre können Nutzer eine Ausnahme beantragen; der Ablauf ähnelt laut GitHub den Ausnahmeverfahren anderer Advanced-Security-Funktionen.
Weiterlesen nach der Anzeige
Während der öffentlichen Vorschau ist der Dienst kostenlos. Für den regulären Betrieb kündigt GitHub eine nutzungsabhängige Abrechnung ähnlich der von GitHub Actions an. Einen Termin für die allgemeine Verfügbarkeit oder konkrete Preise nennt die Ankündigung nicht. GitHub will während der Preview-Phase die zugrunde liegende Infrastruktur ausbauen und weitere Funktionen nach Kundenbedarf ergänzen.
GitHub hatte bereits im Juni strengere Regeln für Installationsskripte in npm angekündigt. Mit npm 12 sollten Skripte aus Abhängigkeiten nicht mehr automatisch, sondern nur nach ausdrücklicher Freigabe laufen.
(fo)