GitHub härter npm gegen Supply-Chain-Angriffe durch standardmäßige Skriptblockierung
In einem bedeutenden Schritt zur Stärkung der Sicherheit von Software-Lieferketten implementiert **GitHub** 'breaking changes' in **npm** Version 12, die für die Veröffentlichung im nächsten Monat geplant ist. Das Update deaktiviert standardmäßig die automatische Ausführung von Installationsskripten und adressiert damit direkt einen kritischen Angriffsvektor, der von bösartigen Paketen missbraucht wird.
Die Sicherheit von Software-Lieferketten ist zu einem vorrangigen Anliegen für IT-Sicherheitsexperten geworden, wobei **npm**'s Paketmanager ein häufiges Ziel darstellt. **GitHub**, der Hüter von **npm**, ergreift entschlossene Maßnahmen, um diese Risiken zu mindern, indem es in der kommenden **npm** Version 12 'breaking changes' einführt.

### Installationsskripte standardmäßig deaktivieren
Der Kern des Updates liegt in der standardmäßigen Deaktivierung von Installationsskripten. Diese Änderung bekämpft direkt Angriffstechniken, die den `npm install`-Befehl nutzen, um bösartige Codeausführung über **npm**-Lifecycle-Hooks auszulösen. **GitHub** hat Installations-Lifecycle-Skripte als die "größte Angriffsfläche für Codeausführung im **npm**-Ökosystem" identifiziert.
Derzeit führt `npm install` Skripte aus jeder transitiven Abhängigkeit aus. Das bedeutet, dass ein einzelnes kompromittiertes Paket irgendwo im Abhängigkeitsbaum beliebigen Code auf der Maschine eines Entwicklers oder auf einem CI-Runner ausführen kann. Durch die Blockierung dieser Verhaltensweisen erfordert **npm** nun die ausdrückliche Zustimmung des Benutzers, bevor Code während der Installation automatisch ausgeführt wird.
### Wichtige Änderungen in npm v12
Die bevorstehenden Änderungen sind umfassend und zielen auf mehrere gängige Angriffsvektoren ab:
* `npm install` wird keine `preinstall`, `install` oder `postinstall` Skripte von Abhängigkeiten mehr ausführen, es sei denn, sie sind im Projekt ausdrücklich erlaubt.
* `npm install` wird keine **Git**-Abhängigkeiten mehr auflösen, weder direkt noch transitiv, es sei denn, sie sind ausdrücklich über `--allow-git` erlaubt.
* `npm install` wird keine Abhängigkeiten von Remote-URLs mehr auflösen, wie z.B. `https`-Tarballs, es sei denn, sie sind ausdrücklich über `--allow-remote` erlaubt.
Dies gilt auch für native `node-gyp`-Builds, bei denen ein Paket mit einer `binding.gyp`, aber ohne explizites Installationsskript, immer noch blockiert wird, da **npm** implizit ein `node-gyp rebuild` dafür ausführt. Ebenso werden `prepare`-Skripte von **Git**-, Datei- und Link-Abhängigkeiten blockiert.
### Minderung von Git-Abhängigkeits-Exploits
Durch die Standardeinstellung von `--allow-git` auf `none` schließt **GitHub** einen entscheidenden Pfad zur Codeausführung, bei dem die `.npmrc`-Konfigurationsdatei einer **Git**-Abhängigkeit die **Git**-Executable überschreiben konnte. Diese Schwachstelle bestand selbst mit dem `--ignore-scripts`-Flag, das dazu dient, zu verhindern, dass Pakete während der Installation automatisch integrierte Lifecycle-Skripte ausführen.
### Vorbereitung für Entwickler und Best Practices
**GitHub** empfiehlt Entwicklern, sich auf diese Änderungen vorzubereiten, indem sie auf **npm** 11.16.0 oder neuer aktualisieren. Nach dem Upgrade sollten Entwickler eine normale Installation durchführen und alle angezeigten Warnungen überprüfen. Der empfohlene Workflow ist die Verwendung von `npm approve-scripts --allow-scripts-pending`, um Pakete mit Skripten zu identifizieren, vertrauenswürdige zu genehmigen und dann die aktualisierte `package.json` zu committen.
Nur explizit genehmigte Skripte werden nach dem Upgrade weiterhin ausgeführt, während nicht genehmigte Skripte blockiert werden. Dieser Wechsel von implizitem Vertrauen zu expliziter Genehmigung verbessert die Sicherheitsposition des **npm**-Ökosystems erheblich.
Anfang dieses Jahres führte **npm** auch `min-release-age` ein, eine Einstellung, die darauf abzielt, jede Paketversion abzulehnen, die weniger als eine bestimmte Anzahl von Tagen veröffentlicht wurde. Dies dient als zusätzliche Absicherung gegen neu veröffentlichte bösartige Pakete und stärkt die Software-Lieferkette weiter.