GitHub hat am 20. Oktober 2026 die öffentliche Vorschau seiner Paket-Firewall angekündigt, einer Funktion, die sich zwischen Ausführungsumgebungen, ob GitHub-Actions-Runner oder Coding-Agents, und die vorgelagerten Paketregistries schaltet. Erklärtes Ziel ist es, Angriffe zu blockieren, die genau im Moment der Installation einer Abhängigkeit ausgelöst werden, ein häufiger blinder Fleck bei Sicherheitswerkzeugen, die sich auf bereits veröffentlichten Code konzentrieren.
Was die Firewall tatsächlich prüft
Das Prinzip lässt sich in einem Satz zusammenfassen: Jede Metadatenanfrage oder jeder Paket-Download durchläuft nun einen Kontrollpunkt, bevor er die Build-Umgebung erreicht. GitHub gleicht jede Anfrage mit der Advisory Database ab, um als schädlich oder verwundbar bekannte Pakete zu erkennen, und wendet Lieferketten-Prüfungen an, darunter die Erkennung einer Herabstufung von Attestierungen, ein klassisches Signal dafür, dass ein legitimes Paket kompromittiert wurde.
Zusätzlich lässt sich eine konfigurierbare Abklingzeit, das Cooldown, festlegen, bevor eine neu von einem Maintainer veröffentlichte Version installierbar wird, um Zeit für mögliche Meldungen zu geben.
„Derzeit unterstützt die Paket-Firewall nur npm-Pakete.“
Ein bewusst begrenzter Umfang für den Anfang
GitHub verschweigt den teilweisen Charakter dieses Starts nicht. Das npm-Ökosystem ist das einzige, das in dieser Phase abgedeckt wird: Weder PyPI noch Maven noch eine andere Registry sind in dieser Vorschau enthalten. Die Funktion bleibt zudem GitHub-Enterprise-Cloud-Kunden vorbehalten, Datenresidenz eingeschlossen, was persönliche Konten und Organisationen auf niedrigeren Plänen de facto ausschließt.
Die ausdrückliche Erwähnung von „Coding-Agents“ unter den geschützten Einstiegspunkten ist kein Zufall: Ein autonomer Agent, der Abhängigkeiten installiert, um Code zu testen oder auszuführen, ist ein eigenständiger Angriffsvektor, da er oft mit weniger direkter menschlicher Aufsicht agiert als ein Entwickler, der npm install von Hand eingibt.
Der Punkt knüpft an eine bereits im Mail-Studio-Leitfaden zu KI für Webentwickler beschriebene Entwicklung an: Mehr Autonomie für Coding-Agents bedeutet auch eine größere Angriffsfläche, die es zu berücksichtigen gilt.
Wie die Funktion aktiviert wird
Die Einrichtung folgt drei Schritten. Administratoren legen zunächst eine Richtlinie auf Unternehmensebene fest, einschließlich der Cooldown-Dauer und der aktivierten Prüfungen. Ausführungsendpunkte, Actions-Runner oder Agents, müssen ihre Paketanfragen anschließend über die Firewall leiten, statt direkt auf die npm-Registry zuzugreifen. Ein fälschlich blockiertes Paket kann schließlich Gegenstand einer Ausnahmeanfrage werden, ähnlich wie bei anderen Funktionen von GitHub Advanced Security.
Zur Veranschaulichung ähnelt das allgemeine Prinzip einer clientseitigen Registry-Umleitung:
# .npmrc - veranschaulichendes Beispiel des Routing-Prinzips
# (siehe GitHub-Dokumentation für die genaue Konfiguration)
registry=https://npm.pkg-firewall.example/registry/
always-auth=true
GitHub verweist für die genaue Konfiguration, die über diese einfache Veranschaulichung hinausgeht, auf seine eigene Dokumentation „Protecting endpoints with package firewall“. Teams, die ihre Sicherheitsbeobachtung bereits mit einer Auswahl an Kommandozeilen-Werkzeugen für die Webentwicklung organisieren, finden hier einen naheliegenden Kandidaten, den sie im gleichen Rhythmus wie Dependabot verfolgen können.
Vergleich mit bestehenden Schutzmechanismen
| Funktion | Was sie abdeckt | Zeitpunkt des Eingreifens |
|---|---|---|
| Dependabot alerts | Bekannte Schwachstellen in bereits installierten Abhängigkeiten | Nach der Installation, laufend |
| Secret scanning | Offengelegte Zugangsdaten und Schlüssel in Code oder Paketen | Bei Veröffentlichung oder Erkennung |
| Paket-Firewall | Schädliche oder herabgestufte Pakete vor der Installation (nur npm) | Beim Download |
Ein Abrechnungsmodell nach Vorbild von Actions
Die Vorschau ist kostenlos, doch GitHub kündigt an, dass bei Erreichen der allgemeinen Verfügbarkeit eine nutzungsbasierte Abrechnung greifen wird, ähnlich wie bei Actions. Das Unternehmen betont zudem, die dahinterliegende Infrastruktur weiterhin auszubauen, mit Erweiterungen je nach Kundennachfrage, was eine Ausweitung auf weitere Registries mittelfristig nicht ausschließt.
Was man sich merken sollte
Die Paket-Firewall von GitHub verlagert die Erkennung von Lieferketten-Angriffen auf den Moment der Installation selbst, statt sich allein auf eine nachträgliche Prüfung zu verlassen. Die Vorschau bleibt jedoch auf npm und GitHub Enterprise Cloud beschränkt, was sie vorerst eher zu einem Richtungssignal als zu einem breit angelegten Schutz macht.
Der interessanteste Aspekt dieser Ankündigung ist nicht die Erkennung schädlicher Pakete, ein Feld, das bereits von mehreren Drittanbieter-Werkzeugen besetzt wird, sondern die ausdrückliche Erwähnung von Coding-Agents als zu schützende Angriffsfläche. Je mehr Autonomie diese Agents bei Installations- und Build-Aufgaben gewinnen, desto mehr lohnt es sich, sie wie ein menschliches Konto als zu sichernde Identität zu behandeln, weit über das GitHub-Ökosystem hinaus. — Simon Janvier
Zum Weiterlesen: Die vollständige Ankündigung ist im GitHub-Changelog verfügbar.
