GitHub verschärft npm-Schutz gegen Supply-Chain-Angriffe : Neue 2FA-Freigaben und Installationsregeln sichern Pakete besser ab
Angriffe auf Open-Source-Pakete nehmen massiv zu – nun reagiert GitHub mit neuen Sicherheitsmechanismen für den Node Package Manager. Mit verpflichtender Zwei-Faktor-Freigabe, gestaffelter Veröffentlichung und strenge-ren Installationskontrollen sollen manipulierte Pakete deutlich schwerer in Software-Lieferketten gelangen.
GitHub erweitert die Sicherheitsfunktionen des Node Package Managers (npm) um mehrere neue Schutzmechanismen gegen Supply-Chain-Angriffe. Im Mittelpunkt steht das neue Verfahren „staged publishing“, das Veröffentlichungen erst nach einer zusätzlichen Freigabe durch Maintainer öffentlich zugänglich macht. Bislang konnten neue Paketversionen direkt nach dem Upload installiert werden. Mit staged publishing landet das vorbereitete Paket zunächst in einer Warteschlange. Erst nachdem ein menschlicher Maintainer die Veröffentlichung über eine Zwei-Faktor-Authentifizierung (2FA) bestätigt hat, wird das Paket auf npmjs.com freigegeben. GitHub beschreibt das Verfahren als zusätzlichen „Proof of Presence“-Mechanismus für jede Veröffentlichung. Dadurch sollen kompromittierte Continuous Integration/Continuous Deployment (CI/CD)-Pipelines oder missbrauchte Automatisierungsprozesse weniger Schaden anrichten können.
Schutz auch für automatisierte Build-Prozesse
Die neue Freigabelogik betrifft ausdrücklich auch moderne Trusted-Publishing-Workflows mit OpenID Connect (OIDC). Selbst wenn Builds automatisiert erstellt werden, ist nun eine aktive Freigabe durch einen Maintainer erforderlich. Zur Nutzung von staged publishing müssen Maintainer folgende Voraussetzungen erfüllen:
- Veröffentlichungsrechte für das Paket besitzen
- Das Paket muss bereits im npm-Registry existieren
- 2FA für das Benutzerkonto aktiviert haben
Neue Pakete lassen sich zunächst nicht über das Verfahren veröffentlichen. Für die Nutzung ist außerdem npm Command Line Interface (CLI) ab Version 11.15.0 notwendig. Der eigentliche Upload erfolgt über den Befehl:
npm stage publish
GitHub empfiehlt zusätzlich die Kombination mit Trusted Publishing über OIDC, um Build-Umgebungen kryptografisch abzusichern.
Neue Installationskontrollen für npm
Parallel dazu führt GitHub drei neue Installationsparameter ein. Sie ergänzen das bisherige –allow-git-Flag und erlauben eine granularere Kontrolle darüber, aus welchen Quellen Pakete installiert werden dürfen.
Die neuen Optionen umfassen:
- –allow-file: Steuert Installationen aus lokalen Dateipfaden und lokalen Tarballs
- –allow-remote: Kontrolliert Installationen aus entfernten URLs einschließlich HTTPS-Tarballs
- –allow-directory: Regelt Installationen aus lokalen Verzeichnissen
GitHub erklärt in einem Bericht dazu, Entwickler könnten damit „denselben expliziten Allowlist-Ansatz auf jede nicht aus der Registry stammende Installationsquelle anwenden“. Technisch reduziert das vor allem das Risiko sogenannter Dependency Confusion- oder Loader-Angriffe. Dabei schleusen Angreifer manipulierte Pakete über externe Quellen oder lokale Build-Prozesse in Entwicklungsumgebungen ein.
Open-Source-Ökosystem unter Druck
Die neuen Schutzmaßnahmen kommen zu einem Zeitpunkt, an dem Angriffe auf Open-Source-Ökosysteme stark zunehmen. Besonders problematisch sind automatisierte Kampagnen gegen populäre Pakete und Build-Abhängigkeiten. Als Beispiel nennt der Bericht die Gruppierung TeamPCP. Die Angreifer kompromittieren Open-Source-Pakete in großem Stil und erzeugen dabei eine sich selbst verstärkende Angriffskette: Infizierte Pakete kompromittieren weitere Entwicklerumgebungen, die wiederum neue manipulierte Veröffentlichungen erzeugen.
Gerade npm gilt aufgrund seiner enormen Verbreitung als besonders attraktives Ziel. Viele moderne Anwendungen beziehen hunderte bis tausende Abhängigkeiten direkt aus öffentlichen Registries. Schon einzelne kompromittierte Bibliotheken können daher weitreichende Folgen für Unternehmen und Cloud-Infrastrukturen haben. Mit staged publishing verschiebt GitHub die Sicherheitskontrolle näher an den eigentlichen Veröffentlichungsprozess. Dadurch wird verhindert, dass kompromittierte Automatisierungssysteme unbemerkt Schadcode in produktive Paketversionen einschleusen können.