Supply-Chain-Angriffe auf npm, PyPI und Co. reißen nicht ab. Das haben auch wir in den letzten Wochen mehrfach berichtet. Jetzt gibt es von GitHub eine Antwort: die Package Firewall, die heise im Detail am 23. Oktober 2026 vorgestellt hat.
WAS DIE FIREWALL MACHT
Die Package Firewall sitzt zwischen deinen Rechnern und den öffentlichen Paketquellen. Entwickler, Coding-Agenten und CI/CD-Hosts müssen ihre Anfragen darüber schicken, statt direkt bei der Registry anzuklopfen. Die Firewall prüft dabei sowohl Metadaten-Abfragen als auch Downloads. Aktuell ist sie als Public Preview für Kunden von GitHub Enterprise Cloud verfügbar — auch mit Datenresidenz — und unterstützt zunächst nur npm.
DIE REGELN IM ÜBERBLICK
- Wartefrist: Admins legen ein Mindestalter für neu veröffentlichte Versionen fest. Erst danach darf installiert werden. Das fängt Angriffe ab, die in den ersten Stunden nach einer Veröffentlichung Schaden anrichten.
- Malware- und Lückensperre: Pakete, die als schädlich oder anfällig in der GitHub Advisory Database stehen, werden blockiert.
- Neue Install-Skripte: Bekommt eine Version plötzlich ein
preinstall– oderpostinstall-Skript, kann der Download gestoppt werden. - Attestierungs-Downgrade: Fehlen bei einer Version die SLSA-Attestierungen, die frühere Versionen hatten, schlägt die Firewall an. Das kann auf einen kompromittierten Veröffentlichungsprozess hindeuten.
- Ausnahmen: Wird ein Paket zu Unrecht gesperrt, können Nutzer eine Freigabe beantragen.
WAS ES KOSTET — UND WAS NOCH FEHLT
Die Vorschau ist kostenlos. Für den regulären Betrieb plant GitHub nutzungsabhängige Abrechnung ähnlich wie bei GitHub Actions, Preise gibt es noch nicht. Auch einen Termin für die allgemeine Verfügbarkeit nennt GitHub nicht. Die Grenzen sind klar: Es gibt nur npm, und der Schutz greift ausschließlich, wenn der Verkehr tatsächlich durch die Firewall läuft. Wer einen Rechner vergisst, bleibt ungeschützt.
WARUM DAS FÜR DICH WICHTIG IST
Die Wartefrist ist der unscheinbare Star. Viele Angriffe leben davon, dass eine vergiftete Version in Minuten auf tausenden Build-Servern landet. Wer neue Versionen erst nach 24 oder 72 Stunden zieht, lässt der Community Zeit zum Entdecken. Für Homelab-Betreiber und kleine Teams ohne Enterprise Cloud bleibt die Idee übertragbar: Lockfiles nutzen, Versionen pinnen und neue Releases nicht blind übernehmen.