Ing. Calogero Bono
GitHub hat am 20. Oktober 2026 die Package Firewall vorgestellt, einen Filter, der sich zwischen die Rechner, die Pakete installieren, und die öffentlichen Register schaltet, von denen diese heruntergeladen werden. Heute ist sie in der öffentlichen Vorschau für alle Kunden von GitHub Enterprise Cloud verfügbar und unterstützt nur npm. Ziel ist es, Malware zu stoppen, die genau bei der Installation zuschlägt, ein besonders großes Risiko für KI-Agenten und Build-Systeme, die Abhängigkeiten installieren, ohne dass jemand hinschaut. Wenn du Software entwickelst oder Teams leitest, die das tun, ist das ein Signal, wohin sich die Sicherheit der Lieferkette bewegt.
Einige Begriffe vorab, bevor es um die Fakten geht. Ein Register (oder Registry) ist das Online-Lager, aus dem man Pakete herunterlädt, etwa npm für JavaScript. Eine Abhängigkeit ist ein Stück fremden Codes, das dein Projekt verwendet. CI/CD sind die automatischen Abläufe, die Software kompilieren und veröffentlichen. Eine SLSA-Attestation ist eine überprüfbare Erklärung darüber, wie und von wem ein Paket erstellt wurde. Metadaten sind Informationen über ein Paket, zum Beispiel die Liste der verfügbaren Versionen.
Was ist die Package Firewall von GitHub?
Laut dem offiziellen Changelog von GitHub gab es in letzter Zeit eine regelrechte Welle von Malware-Angriffen, die den Moment der Paketinstallation ausnutzen. Agenten und CI-Runner sind besonders beliebte Ziele, weil sie Abhängigkeiten installieren, um eine Aufgabe oder einen Build zu erledigen, ohne dass ein Mensch dazwischen ist.
Die Firewall sitzt zwischen den Endpunkten oder internen Registern und den vorgelagerten Paket-Repositories. Wie The Hacker News berichtet, beschreibt GitHub sie so. «The firewall inspects both metadata requests and package downloads for signs of malicious activity, acting as an install-time policy gate,» also ein Regelkontrollpunkt, der bei der Installation greift.
Das Thema ist nicht theoretisch. Die Seite The Register berichtete über eine Kampagne, in der Angreifer GitHub-Issues in einen Angriff auf die Lieferkette gegen 61 öffentliche Repositories verwandelt haben sollen, und das in weniger als einer Stunde. Auf der Seite, die uns vorliegt, finden sich keine weiteren Details, deshalb können wir nicht sagen, ob und wie die beiden Meldungen zusammenhängen.
Wie funktioniert sie und welche Kontrollen bietet sie?
Der Ablauf besteht aus zwei Schritten. Zuerst legen Administratoren die Regeln für ihre Enterprise fest. Dann richten KI-Coding-Agenten und CI/CD-Hosts ihre Anfragen auf die Firewall statt direkt auf die öffentlichen Register. Sowohl Metadatenanfragen als auch Downloads laufen über die Firewall, die sie anhand der Richtlinie bewertet.
Die verfügbaren Kontrollen
Aus der Liste von The Hacker News ergeben sich folgende Kontrollen.
- Blockieren bekannter Malware, geprüft anhand der aktiven Warnungen in der GitHub Advisory Database.
- Blockieren nach Schweregrad von Schwachstellen, ebenfalls über die Datenbank. Die Voreinstellung blockiert nur die Stufe «Critical only», du kannst aber auch «High or higher», «Medium or higher» oder «Any severity» wählen.
- Blockieren von Attestation-Downgrades. Die Firewall vergleicht die Attestationen der angefragten Version mit denen früherer Versionen und stoppt den Download, wenn die SLSA-Attestation fehlt.
- Blockieren neuer Installationsskripte, also solcher, die über die Hooks preinstall oder postinstall laufen und dazu missbraucht werden können, sensible Daten zu stehlen.
- Wartezeit (Cooldown), die verhindert, dass Versionen installiert werden, die jünger sind als das konfigurierte Mindestalter.
Der Cooldown kann zwischen 1 und 365 Tagen liegen. Der Standardwert ist 1 Tag, und er wird deaktiviert, wenn man ihn auf 0 setzt.
Und wenn ein harmloses Paket blockiert wird?
Wird ein Paket irrtümlich blockiert, kann der Nutzer eine Ausnahme beantragen. Für GitHub ist der Ablauf ähnlich wie bei anderen Funktionen von GitHub Advanced Security. Laut The Hacker News kann die Anfrage von Administratoren und Verantwortlichen für Sicherheit der Enterprise genehmigt werden.
Was kostet sie und wer kann sie nutzen?
Der Dienst ist in der öffentlichen Vorschau für alle Kunden von GitHub Enterprise Cloud verfügbar, auch in der Version mit Datenresidenz. Während der Vorschau ist er kostenlos. Mit der allgemeinen Verfügbarkeit will GitHub ihn nach dem gemessenen Verbrauch abrechnen, ähnlich wie bei der Abrechnung von Actions.
GitHub erklärt, dass die Vorschau dazu dient, die Infrastruktur auszubauen und Funktionen entsprechend den Wünschen der Kunden zu ergänzen. Für die Einrichtung verweist GitHub auf die Dokumentation Protecting endpoints with package firewall.
Warum ist so viel von Wartezeiten die Rede?
Der Cooldown ist die einfachste und vielleicht verbreitetste Regel. The Hacker News erinnert daran, dass im letzten Jahr ähnliche Wartezeiten bei npm, Python, Visual Studio Code, Ruby, Bun, pnpm und Yarn eingeführt wurden. Das Prinzip ist, die Wahrscheinlichkeit zu senken, dass eine frisch veröffentlichte und nie überprüfte Version sofort in einem Build landet.
Besonders hilft er gegen Angreifer, die das Konto eines Maintainers übernehmen und eine manipulierte Version eines beliebten Pakets veröffentlichen. Die Wartezeit bremst die schnelle Verbreitung, egal ob manuell oder automatisch.
Derselbe Artikel weist darauf hin, dass Rust 1.100, das am 12. November 2026 erscheinen soll, ein konfigurierbares Mindestalter für Veröffentlichungen bei Crates einführen dürfte. Die Option heißt «global-min-publish-age» und steht in der Datei cargo/config.toml. Ohne Angabe gilt eine Standardwartezeit von sieben Tagen.
Die Kehrseite nennt Socket, das von The Hacker News zitiert wird. «The tradeoff is that legitimate fixes have to wait, too, unless developers make an exception,» sagt das Unternehmen. Außerdem könne eine Veröffentlichung, die die Kontrollen umgangen hat, den Cooldown einfach überstehen. Der Wert liegt laut Socket darin, Forschern, Maintainern und Registern Zeit zum Eingreifen zu geben.
Grenzen, die du kennen solltest
- Derzeit unterstützt die Firewall nur npm. Wer mit PHP, Python oder anderen Ökosystemen arbeitet, ist nicht abgedeckt, und die Quellen nennen keine Termine für andere Register.
- Sie ist Kunden von GitHub Enterprise Cloud vorbehalten. Die Quellen sagen nichts zu kleineren Tarifen.
- Wir befinden uns in der Vorschau. Funktionen, Infrastruktur und Preise können sich ändern, und der nutzungsabhängige Preis steht noch nicht fest.
- Unabhängige Daten zur Wirksamkeit haben wir nicht. Die Quellen geben die Aussagen von GitHub wieder, keine Tests mit echter Malware, und zu Fehlalarmen gibt es keine Zahlen.
- Wie Socket betont, macht der Cooldown schädlichen Code nicht harmlos. Eine nicht erkannte Version kann die Wartezeit unbemerkt überdauern.
Was sich für alle ändert, die digital arbeiten
Der praktische Punkt ist, dass sich die Sicherheit von der nachträglichen Kontrolle zur Prüfung vor der Installation verlagert. Wer mit KI-Agenten entwickelt, die selbstständig schreiben und installieren, bekommt damit eine zentrale Regel, statt dem einzelnen Agenten vertrauen zu müssen. Wenn du KI-gestützte Entwicklungswerkzeuge nutzt, lohnt sich ein Blick auf die Risiken, die wir in unserem Artikel über Vibe Coding für kleine und mittlere Unternehmen beschrieben haben.
Für italienische Unternehmen berührt das Thema auch die Compliance. Die Lieferkette der Software gehört zu dem, was wir im Leitfaden zum Lieferantenregister NIS2 behandeln. Nachweisen zu können, dass Pakete einen Filter mit schriftlich festgelegten Regeln durchlaufen, ist ein konkretes Argument, auch wenn keine Quelle die Firewall mit NIS2 verbindet.
Wer viel Open Source nutzt, sollte sich daran erinnern, dass jede Abhängigkeit ein Lieferant ist. Dazu gibt es unsere Vertiefung zu Open Source im Unternehmen. Auch wer kein Enterprise-Kunde ist, kann die Idee mit den vorhandenen Mitteln übernehmen, zum Beispiel mit den Wartezeiten, die manche Paketverwalter anbieten.
Für Build- und Produktionsserver zählen außerdem Updates und Isolation. Wenn du eine von anderen betreute Infrastruktur möchtest, bieten wir Hosting und verwaltete Server an. Wenn du stattdessen ein maßgeschneidertes Projekt planst, findest du den Weg dorthin in der Individualentwicklung von Software.
Unsere Einschätzung
Die Idee ist richtig. Ein Paket zu stoppen, bevor es auf dem Rechner läuft, ist wirksamer, als es danach zu bemerken, und an einer zentralen Stelle zu prüfen, verhindert, dass man sich auf die Disziplin jedes einzelnen Entwicklers oder Agenten verlassen muss. Dass GitHub genau bei den unbeaufsichtigten Agenten ansetzt, halten wir für eine ehrliche Lesart des Problems.
Wir haben zwei Vorbehalte. Der erste ist kommerziell. Ein so nützlicher Schutz, der vorerst den Enterprise-Kunden vorbehalten ist und nach der Vorschau nach Verbrauch bezahlt werden muss, könnte kleine Teams ohne Schutz lassen, obwohl sie oft am stärksten gefährdet sind. Der zweite ist technisch. Viele Kontrollen stützen sich auf die Datenbank von GitHub und auf die Zeit, und die Zeit ist keine Garantie, wie auch Socket selbst einräumt.
Deshalb sehen wir darin keinen endgültigen Schutzschild. Es ist eine zusätzliche Schicht, die nützlich ist, wenn sie durch Überprüfung der Abhängigkeiten, Festlegen fester Versionen und minimale Rechte für Agenten ergänzt wird. Wenn du glaubst, es reiche, die Firewall einzuschalten, wiegst du dich in falscher Sicherheit.
Häufige Fragen
Ist die Package Firewall von GitHub kostenlos?
Ja, aber nur während der Vorschau. GitHub kündigt an, dass sie mit der allgemeinen Verfügbarkeit nach gemessenem Verbrauch abgerechnet wird, ähnlich wie Actions. Die Preise stehen noch nicht fest.
Funktioniert sie nur mit npm?
Ja, derzeit unterstützt sie nur npm-Pakete. Die Quellen nennen keine Termine für andere Ökosysteme. Wenn du andere Sprachen nutzt, musst du dir vorerst andere Schutzmaßnahmen suchen.
Wer kann sie nutzen?
Alle Kunden von GitHub Enterprise Cloud, auch in der Version mit Datenresidenz. Die Quellen erwähnen keine anderen Tarife. Die Administratoren legen die Regeln für die gesamte Enterprise fest.
Was passiert, wenn ein legitimes Paket blockiert wird?
Der Nutzer kann eine Ausnahme beantragen. Laut The Hacker News kann die Anfrage von Administratoren und Verantwortlichen für Sicherheit genehmigt werden. Der Ablauf ähnelt laut GitHub dem anderer Funktionen von Advanced Security.
Reicht die Wartezeit, um Malware zu stoppen?
Nein. Sie verschafft Zeit gegen frisch veröffentlichte Versionen, aber Socket weist darauf hin, dass schädlicher Code mit dem Alter nicht harmlos wird. Eine nicht erkannte Version kann die Wartezeit überstehen.
Worauf du bis zur allgemeinen Verfügbarkeit achten solltest
In den kommenden Monaten lohnt es sich, drei Dinge im Blick zu behalten. Den Verbrauchspreis, den GitHub festlegen wird, eine mögliche Erweiterung über npm hinaus und die Einführung der Mindestwartezeit in Rust 1.100, die für den 12. November 2026 geplant ist. Bis dahin kannst du so vorgehen.
- Liste die Abhängigkeiten auf, die CI und Agenten verwenden, und lege fest, wer ohne Aufsicht was installieren darf.
- Prüfe eine Wartezeit für neue Versionen, wobei du bedenkst, dass sie auch legitime Korrekturen verzögert.
- Erstelle ein Verfahren für Ausnahmen, bei dem ein Verantwortlicher schnell, aber mit schriftlicher Dokumentation genehmigt.
