Malware beim Installieren, und was GitHubs Paket-Firewall prüft

Bei einer bösartigen Abhängigkeit denken die meisten an Code, der Schaden anrichtet, wenn die Anwendung ihn ausführt. GitHub weist in seiner Ankündigung vom 20. Oktober 2026 darauf hin, dass immer mehr Angriffe so lange nicht warten: Sie schlagen während der Installation des Pakets zu und greifen Zugangsdaten vom CI-Runner oder vom Laptop des Entwicklers ab, ohne dass deine Anwendung je eine Zeile des Pakets ausführt. Wenn der erste Test startet, ist das Token schon weg. GitHubs Antwort ist eine Paket-Firewall, jetzt in der Public Preview, und es lohnt sich zu wissen, was sie tut und wie eng ihr Geltungsbereich heute noch ist.

Was die Firewall prüft

Laut GitHub sitzt die Firewall zwischen deinen Endpunkten, also Actions-Runnern und Coding-Agents, und der vorgelagerten Registry und schaut sich sowohl Metadaten-Anfragen als auch Paket-Downloads an. Die Richtlinien sind heute eine konfigurierbare Wartezeit, ein Abgleich mit der GitHub Advisory Database auf Malware- und Schwachstellenwarnungen sowie Lieferkettenprüfungen wie ein Attestierungs-Downgrade. Endpunkte müssen so konfiguriert werden, dass sie die Firewall statt der Registry direkt nutzen, und wird ein Paket versehentlich blockiert, kannst du eine Ausnahme beantragen.

Was sie nicht abdeckt

Sei beim Umfang genau, bevor du darauf planst. GitHub sagt, die Preview richtet sich an Kunden von GitHub Enterprise Cloud, Data Residency eingeschlossen, und unterstützt derzeit nur npm-Pakete. Auf einem Free- oder Team-Plan hast du sie also nicht, und bei einem PHP-Projekt läuft nichts aus deiner Composer-Installation durch sie hindurch. Während der Preview ist sie kostenlos; später soll sie laut GitHub ähnlich wie Actions nach Verbrauch abgerechnet werden.

Auch die Veröffentlichungsseite wurde im selben Monat strenger

Zwei npm-Änderungen vom 2. Oktober drücken vom anderen Ende her. npm stage publish kann jetzt ein komplett neues Paket anlegen: Die erste Version landet in einer Staging-Warteschlange, und ein Maintainer muss sie freigeben, bevor irgendwer sie installieren kann. Außerdem laufen nicht validierte Trusted-Publishing-Konfigurationen jetzt 48 Stunden nach ihrer Erstellung ab. Das senkt das Risiko, einem Repository- oder Projektnamen zu vertrauen, der später den Besitzer wechselt. Validiert wird eine Konfiguration durch ihre erste erfolgreiche Veröffentlichung. npm lehnt zudem Trusted-Publishing-Tokens aus issue_comment-Workflow-Events ab, zusätzlich zur bestehenden Einschränkung für pull_request_target; stattdessen verweist npm auf push, release oder workflow_dispatch.

Was du auf jedem Plan tun kannst

Dieser Teil ist allgemeine Empfehlung, keine Aussage über die Firewall. Checke deine Lockfiles ein und installiere daraus: npm ci für JavaScript, composer install gegen composer.lock für PHP. Lass in der CI eine Advisory-Prüfung laufen. --ignore-scripts überspringt die npm-Lifecycle-Skripte, ist aber keine vollständige Abwehr, denn Angriffe zur Installationszeit laufen nicht nur über Skripte, und manche Pakete brauchen sie wirklich. Eine manuelle Wartezeit heißt einfach: nicht auf eine Version aktualisieren, die in den letzten Tagen erschienen ist, weil die meisten bösartigen Versionen schnell auffallen. Und die wichtigste Schicht: Führe Installationen nicht auf einer Maschine aus, die langlebige Zugangsdaten hält.

npm ci
composer install --no-interaction
composer audit

Diese Seite ist Laravel mit ein wenig JavaScript-Tooling, die Firewall würde also immer nur die kleinere Hälfte davon abdecken. Für die PHP-Seite ist das Gegenstück schlicht: aus dem eingecheckten composer.lock installieren, composer audit in der CI laufen lassen und keine Updates hereinlassen, ohne dass jemand sie gelesen hat. Wenn du auf Enterprise Cloud bist, stellst du einen einzigen Runner auf die Firewall um, beobachtest eine Woche lang, was sie blockiert, und weitest es dann aus. Quelle: GitHub Changelog, Paket-Firewall in der Public Preview.