Mit npm v12 schafft GitHub mehrere sicherheitskritische Standardeinstellungen des Node.js-Paketmanagers ab. Die für Juli 2026 angekündigte Hauptversion führt Installationsskripte aus Abhängigkeiten künftig nicht mehr automatisch aus. Auch Git- und Remote-Abhängigkeiten installiert npm nur noch, wenn Entwickler sie ausdrücklich freigeben. Damit will GitHub einen der wichtigsten Angriffswege in der Software-Lieferkette schließen: die automatische Codeausführung während eines npm install.

npm ist der Standard-Paketmanager des Node.js-Ökosystems und gehört zu den meistgenutzten Paketverwaltungen überhaupt. Moderne Anwendungen ziehen oft Hunderte oder Tausende direkte und indirekte Abhängigkeiten nach. Entsprechend groß ist die Angriffsfläche. Seit Jahren warnen Sicherheitsforscher vor Angriffen auf die Lieferkette, bei denen Schadcode über übernommene Pakete, gestohlene Maintainer-Konten oder manipulierte Installationsskripte in Entwicklungsumgebungen gelangt. Besonders gefährlich sind Mechanismen, die schon beim Installieren eines Pakets Code ausführen – oft, bevor Entwickler die Anwendung überhaupt gestartet haben.

Installationsskripte laufen nicht mehr automatisch

Genau hier setzt die wichtigste Neuerung von npm v12 an. Künftig führt der Paketmanager Installationsskripte aus Abhängigkeiten standardmäßig nicht mehr aus. Das betrifft die Lifecycle-Skripte preinstall, install und postinstall. Auch native Erweiterungen, die npm bislang automatisch über node-gyp kompiliert, baut der Paketmanager nicht mehr ohne Freigabe. Dasselbe gilt für bestimmte prepare-Skripte aus Git-, Datei- oder verlinkten Abhängigkeiten.

Bislang genügt ein einfaches npm install, um solche Skripte automatisch auszuführen. Viele Pakete nutzen den Mechanismus für legitime Zwecke, etwa um zusätzliche Binärdateien herunterzuladen oder native Komponenten zu kompilieren. Dieselbe Funktion gilt aber seit Jahren als attraktiver Angriffsweg: Über ein manipuliertes Installationsskript lässt sich Schadcode bereits während der Installation ausführen. Der Code kann zum Beispiel Umgebungsvariablen auslesen, Zugangsdaten abgreifen oder weitere Schadsoftware nachladen.

Freigaben per Allowlist

An die Stelle des automatischen Ausführens tritt ein Modell mit Freigabeliste. Entwickler bestimmen künftig selbst, welche Pakete ihre Installationsskripte ausführen dürfen. Diese Freigaben hinterlegt npm im Projekt, sodass Teams sie zusammen mit dem Quellcode versionieren können.

Wer früh umstellen will, kann das bereits tun: Schon npm 11.16.0 warnt vor Skripten, die der Paketmanager künftig blockiert. Mit dem Befehl npm approve-scripts --allow-scripts-pending lässt sich prüfen, welche Abhängigkeiten betroffen wären; mit npm approve-scripts lassen sich die vertrauenswürdigen Pakete anschließend freigeben.

Git- und Remote-Abhängigkeiten unter Vorbehalt

Auch beim Umgang mit Git-Abhängigkeiten zieht npm die Zügel an. Pakete, die direkt aus einem Git-Repository stammen, blockiert der Paketmanager künftig standardmäßig; Entwickler müssen solche Quellen ausdrücklich erlauben. GitHub begründet den Schritt mit einem Angriffsweg, über den sich aus einer Git-Abhängigkeit heraus Code ausführen ließ – selbst dann, wenn Installationsskripte eigentlich unterdrückt waren. Hinzu kommt, dass sich Git-Abhängigkeiten generell schwerer kontrollieren lassen als Pakete aus dem regulären npm-Registry.

Eine ähnliche Hürde gilt künftig für Remote-Abhängigkeiten, also Pakete, die direkt von einer URL stammen, etwa als TAR-Archiv per HTTPS. Auch sie installiert npm nur noch nach ausdrücklicher Freigabe. Solche Abhängigkeiten umgehen die übliche Registry-Infrastruktur und erschweren es, ihre Herkunft nachzuvollziehen. GitHub will so verhindern, dass externe Quellen unbemerkt in die Abhängigkeitskette geraten.

Was Entwickler jetzt tun sollten

Mehr Sicherheit bedeutet für Entwickler und Unternehmen zunächst mehr Aufwand. Wer bislang auf Installationsskripte, Git-Abhängigkeiten oder externe Paketquellen setzt, muss seine Build- und CI/CD-Prozesse prüfen und die nötigen Komponenten freigeben. GitHub rät, schon jetzt auf npm 11.16.0 oder neuer zu wechseln und die ausgegebenen Warnungen auszuwerten.

Alle Probleme der JavaScript-Lieferkette löst npm v12 allerdings nicht. Schadcode, der direkt im Anwendungscode eines Pakets steckt, gelangt weiterhin auf die Systeme. Auch kompromittierte Maintainer-Konten, Typosquatting oder verwundbare Bibliotheken fängt der neue Ansatz nicht ab. Für die Sicherheit von Entwicklungs- und Build-Umgebungen dürfte er dennoch eine der weitreichendsten Änderungen der vergangenen Jahre sein.

Weitere Details nennt GitHub im Changelog-Eintrag zu den anstehenden Breaking Changes für npm v12.

(fo)