GitHub hat die Package Firewall für alle Kunden von GitHub Enterprise Cloud in die öffentliche Vorschau geholt – einschließlich der Variante mit Data Residency. Der Dienst sitzt zwischen Endpunkten, internen Registries und den Upstream-Paketquellen und arbeitet als install-time Policy Gate: Er prüft Metadatenabfragen und Downloads von npm-Paketen und blockiert hochriskante Versionen, bevor sie im Build landen. Eine CVE gibt es nicht, einen CVSS-Score ebenso wenig – die Firewall ist keine Schwachstelle, sondern eine Gegenmaßnahme gegen Supply-Chain-Angriffe.
Wie die GitHub Package Firewall npm-Installationen prüft
Die Firewall ist kein Scanner, der Pakete nachträglich bewertet, sondern eine zentrale Instanz, die jede Anfrage sieht. Damit die Regeln greifen, müssen CI/CD-Hosts und Coding-Agenten ihre Anfragen über die Firewall statt direkt an die öffentlichen Registries schicken – wer seine Runner nicht umkonfiguriert, umgeht den Schutz stillschweigend. Durch die Prüfung laufen dabei nicht nur die Downloads, sondern auch Versionsabfragen, also Paketname und angefragte Version. Riskante Versionen lassen sich damit schon in der Auflösungsphase erkennen und vor der eigentlichen Installation stoppen. In der Vorschau unterstützt der Dienst ausschließlich npm; Support für PyPI, Maven oder NuGet kündigt GitHub nicht an.
Cooldown, Advisory-Abgleich und Attestation-Downgrade
Vier Kontrollen stehen nach derzeitigem Stand bereit:
- Cooldown-Periode: Neue Versionen lassen sich für eine konfigurierbare Wartezeit sperren – standardmäßig ein Tag, einstellbar von einem bis 365 Tagen und auch abschaltbar. GitHubs eigenes Changelog quantifiziert die Frist nicht. Die Wartezeit ist der interessanteste Baustein, weil sie nicht auf bekannte Fälle reagiert, sondern auf Zeit: Eine frisch veröffentlichte Malware-Version soll den Build nicht mehr erreichen, bevor sie überhaupt jemand gemeldet hat.
- Abgleich mit der GitHub Advisory Database: Meldungen zu Malware und Schwachstellen fließen in die Entscheidung ein. Das ist der reaktive Teil und entspricht dem, was Registry-Proxys seit Jahren tun.
- Attestation-Downgrade-Erkennung: Fehlen einer neuen Version SLSA-Attestierungen, die frühere Versionen trugen, blockiert die Firewall den Download. GitHub wertet das als möglichen Hinweis auf einen kompromittierten Veröffentlichungsprozess – also auf einen übernommenen Publish-Account, der die Provenienz der Vorgängerversionen nicht mehr reproduzieren kann.
- Installationsskript-Filter: Neu hinzugekommene
preinstall– oderpostinstall-Skripte lassen sich ausfiltern. Genau an dieser Stelle greifen npm-Angriffe seit Jahren Zugangsdaten direkt bei der Installation ab, bevor irgendein Anwendungscode ausgeführt wird.
Vorgeschaltet ist eine Ankündigung, die GitHub bereits im Juni gemacht hatte: Mit npm 12 sollen Skripte aus Abhängigkeiten nicht mehr automatisch laufen, sondern erst nach ausdrücklicher Freigabe. Ein Termin für die finale Umsetzung steht nicht fest.
Warum die Firewall auf CI-Runner und Coding-Agenten zielt
GitHub begründet den Schritt mit einer Flut von Malware-Angriffen, die Systeme im Moment der Installation ausnutzen. Agenten und CI-Runner seien besonders gefährdet, weil sie Abhängigkeiten ohne menschliche Kontrolle nachziehen. Das ist eine Risikoeinschätzung des Herstellers, keine Messung: Konkrete Kampagnen, betroffene Paketnamen oder Opferzahlen nennt GitHub nicht.
Der strukturelle Punkt dahinter ist trotzdem stichhaltig. Wer einen Agenten laufen lässt, der selbstständig Abhängigkeiten auswählt und aktualisiert, hat keinen Menschen mehr im Loop, der vor dem npm install einen Blick auf Versionsnummer und Skripte wirft. Klassische Werkzeuge setzen an genau dieser Stelle zu spät an: Advisory-Datenbanken kennen eine bösartige Version erst, nachdem sie gemeldet wurde. Die Cooldown-Periode dreht die Logik um und bremst die Veröffentlichung selbst – nicht die bereits bekannte Malware. Die Attestation-Prüfung adressiert den zweiten blinden Fleck, nämlich die Frage, ob eine Version tatsächlich aus der erwarteten Pipeline stammt.
Offene Punkte: Preise, Bypass-Schutz und weitere Ökosysteme
In der Vorschau ist die Firewall kostenlos. Bei General Availability will GitHub nutzungsabhängig abrechnen, ähnlich dem Modell von GitHub Actions – ein GA-Termin und konkrete Preise sind nicht genannt. Wer die Preview produktiv einsetzt, sollte die Abrechnungsfrage deshalb vor der Freigabe klären und nicht danach.
Ebenfalls offen ist der Erzwingungsmechanismus. Die Firewall ist nur so gut wie die Registrie-Konfiguration der Clients; wie Unternehmen verhindern, dass ein Container oder Entwickler-Rechner weiterhin direkt gegen registry.npmjs.org auflöst, bleibt offen. Praktisch braucht es dafür einen erzwungenen Registry-Rewrite oder eine Netzwerk-Policy – beides ist Sache der betreibenden Teams, nicht der Firewall.
Bei irrtümlicher Sperre können Nutzer eine Ausnahme beantragen; der Freigabeprozess läuft wie bei anderen GitHub Advanced Security-Funktionen über Admins. Ob der Installationsskript-Filter standardmäßig aktiv ist oder opt-in, ist unklar. Wirksamkeitsdaten fehlen vollständig: Es gibt keine False-Positive-Rate und keine Zahlen dazu, wie viele Builds die Prüfung blockiert.
Fazit
Für Enterprise-Cloud-Kunden lohnt sich ein Blick in die Preview, bevor die Preisfrage geklärt ist – der Aufwand für das Aktivieren ist gering, der Nutzen hängt aber an zwei Hausaufgaben. Erstens: die Cooldown-Periode nicht beim Standard von einem Tag belassen, sondern an das eigene Release-Tempo anpassen; ein Tag fängt unentdeckte Malware nicht zuverlässig ab. Zweitens: prüfen, ob die Runner und Agenten wirklich über die Firewall auflösen und nicht an ihr vorbei.
Ein Patch ist nicht nötig, weil keine Schwachstelle adressiert wird. Dringlichkeit entsteht hier nicht durch einen Exploit im Umlauf, sondern durch die Lücke zwischen npm-only und dem Rest des Ökosystems: Solange PyPI, Maven und NuGet außen vor bleiben, deckt die Firewall nur einen Teil der Abhängigkeiten ab, die ein Agent nachzieht.