GitHub Package Firewall: Schutz vor bösartigen npm-Paketen

Wenn ein KI-Agent für dich eine App baut, installiert er Dutzende npm-Pakete, ohne dass du auch nur eines davon anschaust. Genau an dieser Stelle setzt GitHub jetzt eine Firewall an.

Was passiert ist

GitHub hat am 20. Oktober 2026 die Package Firewall als Public Preview gestartet. Sie sitzt zwischen deinen Endpunkten und den öffentlichen Paket-Registries. Jede Metadaten-Anfrage und jeder Download läuft durch sie hindurch und wird gegen eine Richtlinie geprüft, die ein Enterprise-Admin zentral festlegt.

Der Anlass ist eine Welle von Schadsoftware, die beim Installieren von Paketen ausgeführt wird. GitHub schreibt im Changelog, dass Agents und CI-Runner besonders gefährdet sind, weil sie Abhängigkeiten ohne menschliche Kontrolle installieren, um eine Aufgabe zu erledigen oder einen Build abzuschließen. Wie groß das Problem ist, hat GitHub schon im September 2025 beschrieben: Der Wurm Shai-Hulud kaperte Maintainer-Konten, schleuste Post-install-Skripte in beliebte Pakete ein und stahl Zugangsdaten. GitHub entfernte damals über 500 kompromittierte Pakete aus der Registry.

Was die Firewall prüft. Die Dokumentation nennt fünf Richtlinien, die der Admin einzeln einstellen kann (Stand: Oktober 2026):

Richtlinie	Standard	Was sie tut
Bekannte Malware blockieren	an	Abgleich mit aktiven Malware-Advisories in der GitHub Advisory Database
Schwachstellen blockieren	nur kritisch	Mindestschweregrad wählbar: nur kritisch, hoch oder höher, mittel oder höher, alle
Attestation-Downgrades blockieren	an	Sperrt Versionen ohne SLSA-Attestation, wenn frühere Versionen eine hatten
Neue Install-Skripte blockieren	an	Sperrt Versionen, die neu ein preinstall- oder postinstall-Skript einführen
Mindestalter	1 Tag	Zwischen 1 und 365 Tagen einstellbar, 0 schaltet die Prüfung ab

Das Mindestalter ist die Wartezeit aus der Ankündigung: Eine frisch veröffentlichte Version wird erst durchgelassen, wenn sie alt genug ist. Dahinter steckt die Erfahrung, dass bösartige Versionen meist innerhalb weniger Stunden oder Tage entdeckt und aus der Registry entfernt werden. Wer nicht sofort auf die neueste Version springt, überspringt oft das gefährliche Zeitfenster.

Die GitHub Advisory Database, gegen die abgeglichen wird, führt neben geprüften Schwachstellen auch Malware-Advisories. Die stammen vom npm-Sicherheitsteam und aus dem OpenSSF-Projekt „Malicious Packages“. Für Malware gibt es keine Fix-Version, die einzige sichere Maßnahme ist, das Paket nicht zu verwenden.

Wie die Anbindung funktioniert. Der Endpunkt bekommt statt der öffentlichen npm-Registry eine Enterprise-spezifische Adresse der Firewall in seine .npmrc eingetragen. Für die Authentifizierung braucht jede Anfrage ein Token eines Nutzers oder Bot-Kontos, das Mitglied des Enterprise ist. Laut Dokumentation genügt dafür die Berechtigung „Read-only access to public repositories“. Konkrete Anleitungen gibt es bisher für npm direkt und experimentell für JFrog Artifactory als vorgeschalteten Proxy. Eine eigene Integration für GitHub Actions oder den Copilot Coding Agent beschreibt die Dokumentation nicht; CI-Runner und KI-Agenten werden nur allgemein als Einsatzbereiche genannt.

Was bei einem Fehlalarm passiert. Blockiert die Firewall ein Paket, enthält die Fehlermeldung in npm oder im CI-Log einen Link zu einem Formular. Repository, Paketname und Version sind vorausgefüllt, der Nutzer ergänzt eine Begründung. Ein Admin prüft die Anfrage im Enterprise unter „Security and quality“, kann eine Version oder mit * alle Versionen freigeben, und die Ausnahme landet als Override in der Richtlinie.

Verfügbarkeit und Preis. Die Firewall gibt es laut Changelog für alle Kunden von GitHub Enterprise Cloud, auch mit Data Residency. Sie unterstützt derzeit nur npm. In der Preview ist sie kostenlos, mit der allgemeinen Verfügbarkeit soll nach Verbrauch abgerechnet werden, „similar to Actions billing“. Der Enterprise-Plan selbst startet laut Preisseite bei 21 US-Dollar pro Nutzer und Monat für die ersten zwölf Monate (Stand: Oktober 2026). In der Community-Diskussion zur Preview wird Python als nächstes Ökosystem genannt und konfigurierbare Upstream-Registries sind vor der allgemeinen Verfügbarkeit geplant. Kritik gibt es dort an der Pflicht, ein persönliches Token zu hinterlegen.

Was es für dich bedeutet

Du baust als Selbstständige oder kleines Team mit Claude Code, Cursor oder Copilot eine App? Dann betrifft dich das Problem, das GitHub hier löst, direkt. Der Agent entscheidet, welche Pakete er installiert, und ein einzelnes bösartiges Paket kann beim Installieren deine Zugangsdaten, API-Keys oder Kundendaten abgreifen. Was ein KI-Agent so autonom erledigt, ist Stärke und Risiko zugleich.

Die Firewall selbst ist für die meisten von euch nicht erreichbar. Sie setzt GitHub Enterprise Cloud voraus. Für ein Zwei-Personen-Team mit einer App im Store ist das weder preislich noch organisatorisch sinnvoll. Wer in einem größeren Unternehmen arbeitet, das Enterprise Cloud ohnehin nutzt, sollte die Preview jetzt kostenlos testen. Mein Tipp: das Mindestalter deutlich über den Standard von einem Tag heben und sich auf Bypass-Anfragen aus dem Team einstellen.

Das Prinzip kannst du trotzdem übernehmen. Drei Dinge lassen sich ohne Enterprise-Vertrag umsetzen:

• Wartezeit für neue Versionen. Dependabot, das in GitHub-Repositories Abhängigkeiten aktualisiert, kennt eine Cooldown-Option. Ohne eigene Angabe wartet es 3 Tage, bevor es eine neue Version vorschlägt. Wichtig: Diese Wartezeit gilt nur für Versions-Updates, nicht für Sicherheitsupdates. Die Package Firewall greift dagegen beim Installieren, also auch dann, wenn ein Agent spontan ein neues Paket hinzufügt.
• Agent nicht blind laufen lassen. Bei meinem eigenen Agenten Sokrates läuft jede Aktion mit Außenwirkung durch ein Studio mit Freigabe. Beim Coden heißt das: Lass dir anzeigen, welche Pakete der Agent neu installiert, bevor du den Stand übernimmst. Wie das im Alltag aussieht, beschreibe ich in Sokrates: Wie mein KI-Agent sieben Marken steuert.
• Keine Zugangsdaten auf dem Rechner, auf dem der Agent arbeitet. Shai-Hulud hat npm-Tokens und andere Secrets gestohlen. Je weniger davon ein installiertes Skript finden kann, desto geringer der Schaden.

Nur npm ist abgedeckt. Wer mit Python, PHP oder anderen Sprachen arbeitet, bekommt von der Firewall vorerst nichts. Dass Sicherheitslücken nicht an der Sprache hängen, hat die Woche gezeigt: Beim PHP-Problem PHP2Shell hat KI sogar beim Finden der Lücke mitgeholfen. Angreifer nutzen KI genauso wie Verteidiger.

Ich finde den Schritt richtig, auch wenn er zunächst nur Großkunden erreicht. Die Firewall macht sichtbar, worüber bislang kaum jemand spricht: Coding-Agents installieren Software mit denselben Rechten wie du, nur schneller und ohne nachzufragen. Wer das in seinem Prozess nicht abfängt, sollte es wenigstens wissen.

Quellen

• GitHub Changelog, 20.10.2026: GitHub package firewall in public preview
• GitHub Docs: Protecting endpoints with package firewall
• GitHub Community: Diskussion zur Public Preview
• GitHub Docs: About the GitHub Advisory Database
• GitHub Docs: Dependabot options reference, Abschnitt cooldown
• GitHub Blog, 22.09.2025: Our plan for a more secure npm supply chain
• GitHub: Pricing

Häufige Fragen

Was ist die GitHub Package Firewall?

Ein Dienst von GitHub, der zwischen deinen Endpunkten (CI-Runner, Coding-Agents, Entwicklerrechner) und der npm-Registry sitzt. Jeder Download wird gegen Richtlinien geprüft, etwa Abgleich mit der GitHub Advisory Database, ein Mindestalter für neue Versionen und Sperren für neu hinzugefügte Install-Skripte. Seit dem 20. Oktober 2026 ist sie als Public Preview verfügbar.

Wer kann die GitHub Package Firewall nutzen?

Stand Oktober 2026 nur Kunden von GitHub Enterprise Cloud, inklusive der Variante mit Data Residency. In der Preview ist sie kostenlos, mit der allgemeinen Verfügbarkeit soll nach Verbrauch abgerechnet werden, ähnlich wie bei GitHub Actions. Free- und Team-Pläne sind nicht dabei.

Welche Paket-Ökosysteme unterstützt die Package Firewall?

Aktuell ausschließlich npm, also JavaScript- und TypeScript-Pakete. Python, PHP oder andere Ökosysteme sind noch nicht abgedeckt.

Was passiert, wenn die Firewall ein Paket blockiert, das ich brauche?

Die Fehlermeldung in npm oder im CI-Log enthält einen Link zu einem Formular für eine Ausnahme. Ein Enterprise-Admin prüft die Anfrage und kann die Version oder alle Versionen des Pakets freigeben. Genehmigte Ausnahmen landen als Override in der Richtlinie.