GitHub startet Package Firewall als Preview für Enterprise Cloud
GitHub hat eine öffentliche Preview seiner Package Firewall gestartet, um Schadcode bereits bei der Paketinstallation zu blockieren. Die Funktion bleibt jedoch GitHub Enterprise Cloud vorbehalten und unterstützt vorerst nur npm.
GitHub hat am 20. Okt. 2026 im hauseigenen Blog die Public Preview seiner Package Firewall angekündigt. Dabei handelt es sich um eine Prüfschicht, die bösartige Skripte abfangen soll, wenn Entwickler-Rechner, CI-Runner oder autonome Coding-Agenten Abhängigkeiten herunterladen und installieren. Die Funktion steht allen Kundinnen und Kunden von GitHub Enterprise Cloud (GHEC) zur Verfügung, einschließlich Organisationen mit lokaler Datenhaltung (Data Residency).
Wer die Firewall nutzen kann und wie sie abgerechnet wird
Die Package Firewall ist nicht für alle GitHub-Pläne verfügbar. Sie bleibt Organisationen auf GitHub Enterprise Cloud vorbehalten; persönliche Accounts (Free und Pro) sowie GitHub-Team-Tarife werden nicht unterstützt.
| Tarif | Package-Firewall-Unterstützung | Preview-Preis | Preis bei allgemeiner Verfügbarkeit (GA) | Unterstützte Ökosysteme |
|---|---|---|---|---|
| GitHub Free / Team | Nicht unterstützt | Nicht zutreffend | Nicht zutreffend | Nicht zutreffend |
| GitHub Enterprise Cloud (GHEC) | Unterstützt (inkl. Data Residency) | Kostenlos | Nutzungsbasierte Abrechnung (geplant) | npm (einzeln) |
Während der aktuellen Public-Preview-Phase lässt sich die Firewall ohne zusätzliche Kosten nutzen. Sobald die Funktion allgemein verfügbar (GA) ist, will GitHub auf ein nutzungsbasiertes Abrechnungsmodell umstellen, ähnlich wie bei GitHub Actions. Genaue Tarife und ein Zeitpunkt für die finale Freigabe wurden noch nicht genannt.
Was die Firewall prüft und wo die Grenzen liegen
Klassische Sicherheitsprüfungen in der Software-Lieferkette setzen oft erst nach dem Commit an, etwa durch Repository-Scans oder Benachrichtigungen über bekannte Sicherheitslücken. Angreifer nutzen jedoch zunehmend Installations-Hooks (wie preinstall-Skripte), um schon beim Einrichten von Paketen Umgebungsvariablen und geheime API-Schlüssel abzugreifen, bevor der eigentliche Anwendungscode überhaupt ausgeführt wird. Autonome Coding-Agenten und CI-Runner sind dafür besonders anfällig, weil sie Pakete eigenständig und ohne manuelle Prüfung nachladen.
Die Package Firewall klinkt sich zwischen die Endpunkte und das öffentliche Register (registry.npmjs.org) ein und prüft sowohl Metadaten als auch heruntergeladene Archive (Tarballs) in Echtzeit. Administratorinnen und Administratoren können vier zentrale Richtlinien festlegen:
- Bekannte Schadsoftware blockieren: Pakete, die in der GitHub Advisory Database als bösartig geführt werden, werden sofort abgewiesen.
- Schwachstellen-Warnungen berücksichtigen: Versionen mit gemeldeten Sicherheitslücken oberhalb eines gewählten Schweregrads (etwa Critical oder High) werden gesperrt.
- Attestierungs-Downgrades unterbinden: War eine frühere Paketversion mit einer kryptografischen Provenienz-Attestierung (dem Nachweis eines geprüften Builds) versehen, während die neu angeforderte Version dieses Zertifikat nicht mehr enthält, wird das Update als potenziell manipuliert eingestuft und blockiert.
- Abkühlphase für Neuveröffentlichungen: Frisch veröffentlichte Paketversionen werden für eine definierte Zeitspanne zurückgehalten, damit die Open-Source-Community verdächtige Aktivitäten prüfen und melden kann.
Die größte Einschränkung im aktuellen Stand: Die Package Firewall unterstützt ausschließlich npm-Pakete. Andere weit verbreitete Paketmanager wie PyPI (Python), Maven (Java) oder Cargo (Rust) können über diese Schnittstelle bislang nicht abgesichert werden.
Einrichtung und Tücken im Ausnahme-Workflow
Um die Package Firewall einzurichten, aktivieren Verantwortliche die entsprechende Richtlinie in den Enterprise-Einstellungen und passen die Konfiguration der Paketmanager (.npmrc) auf Entwickler-Rechnern und CI-Systemen so an, dass Anfragen über den Firewall-Endpunkt geleitet werden.
Wird ein legitimes internes Paket oder eine dringende Version fälschlicherweise blockiert (False Positive), geben das Terminal oder die CI-Protokolle eine direkte URL für Ausnahmeanträge aus. Entwicklerinnen und Entwickler können dort eine Begründung einreichen, die das Sicherheitsteam über einen Freigabeprozess ähnlich wie bei GitHub Advanced Security (GHAS) genehmigen kann.
In Umgebungen mit autonomen Agenten, in denen Dutzende Hintergrundprozesse parallel laufen, können solche Fehlalarme jedoch die gesamte Pipeline lahmlegen, bis eine Person den Antrag manuell freigibt. Zu lang gewählte Abkühlzeiten verzögern zudem reguläre Abhängigkeits-Updates. Es empfiehlt sich daher, mit kurzen Fristen zu starten und zuständige Personen für Ausnahmegenehmigungen vorab klar zu benennen.
Worauf jetzt zu achten ist
GitHub plant, die Infrastruktur nach Kundenfeedback schrittweise auszubauen und weitere Funktionen bereitzustellen. Entscheidend für Entwicklerteams wird sein, wann die Unterstützung auf Ökosysteme wie PyPI ausgeweitet wird und wie stark die spätere Abrechnung nach Nutzung die CI-Budgets belasten wird.
Quellen
- GitHub package firewall in public preview (The GitHub Blog)
- Protecting endpoints with package firewall (GitHub Docs)
Quelle: github.blog