npm fällt in letzter Zeit vermehrt durch Supply-Chain-Attacken auf. Es hat mit Axios und Tanstack auch sehr populäre und vielgenutzte Projekte getroffen. Um die Pakete aus der npm-Registry führt jedoch trotzdem in moderner Webentwicklung kein Weg vorbei. In diesem Blogbeitrag möchte ich Gegenmaßnahmen beschreiben, die das Risiko von Supply-Chain-Attacken eindämmen können. Insbesondere Version 12 von npm bringt hier einige Neuerungen mit, die ein Update des Paketmanagers rechtfertigen.
Install-Skripte deaktivieren
Ein beliebter Angriffsvektor im Npm-Ökosystem sind die Install-Skripte. So wird etwa das Postinstall-Skript bei der Installation eines Paketes ausgeführt, ohne dass Nutzer:innen dies mitbekommen oder bestätigen müssen. Doch wieso gibt es diese Skripte überhaupt?
Einige Pakete nutzen diese Skripte, um etwa passende Binaries für das Betriebssystem herunterzuladen. Ein bekanntes Beispiel hierfür ist etwa esbuild, welches auch Teil der Angular CLI ist.
Mittlerweile deaktivieren npm ab Version 12 und pnpm ab Version 10 diese Skripte standardmäßig. Nutzer:innen behalten trotzdem die Kontrolle: Der Paketmanager informiert über ein Paket, was hätte ausgeführt werden sollen. Dies ermöglicht es Entwickler:innen das entsprechende Skript zu prüfen. Außerdem lassen sich bei Bedarf explizite Ausnahmen definieren, um die Ausführung von Skripten für vertrauenswürdige Packages zu erlauben. In meiner Erfahrung ist dies jedoch nicht notwendig.
Die Installation von Paketversionen blockieren, die zu neu sind
Das npm-Ökosystem ist schnelllebig. Neue Versionen von Paketen erscheinen ständig. Dies machen sich Angreifer zu nutze: Sie übernehmen Pakete, veröffentlichen eine neue Version, in die sie Schadcode einbetten und Nutzer:innen laden diese nichtsahnend herunter. In der Regel wird ein übernommenes Paket relativ schnell identifiziert und npm entfernt die betroffene Version aus der Registry.
Zum Schutz vor dieser Bedrohung bieten die Paketmanager die Einstellung einer sogenannten Cooldown-Phase an. Eine Version eines Packages wird nicht installiert, wenn sie nicht mindestens dem Alter der Cooldown-Zeit entspricht.
pnpm bietet den Konfigurationsparameter minimumReleaseAge. Seit pnpm 11 ist dieser Wert standardmäßig auf 1440 Minuten gestellt, was 24 Stunden entspricht.
npm hat in Version 11.10 den Konfigurationsparameter min-release-age eingeführt. Dieser ist allerdings in der Standardkonfiguration allerdings nicht gesetzt. Das muss man selbst machen.
Im Moment ist ein betroffenes Package nach 24 Stunden entfernt, es kann aber sicherlich nicht schaden, den Wert auf ein langes Wochenende zu erhöhen. Für diesen Konfigurationsparameter gibt es einige Konfigurationseinstellungen, etwa Ausnahmen, die in der pnpm-Dokumentation und npm-Dokumentation beschrieben sind.
Auf der Website cooldowns.dev sind Anleitungen zur Konfiguration der Cooldown-Phase für diverse weitere Paketmanager zu finden.
Exotische Pakete blockieren
npm-Pakete können aus der npm-Registry geladen werden, aber sie können auch als Tar-Archiv von einem beliebigen Server geladen werden. Außerdem können Pakete als Git-Repositiories, Branches und Commits definiert werden. Dieses Verhalten mag für direkte Abhängigkeiten noch akzeptabel sein, schließlich wählen die Entwickler:innen ihr eigenes Schicksal, spätestens bei Sub-Dependencies wird es aber unschön und undurchsichtig.
In npm gibt es seit neuestem zwei Konfigurationsparameter: allow-git und allow-remote. Allow-git ermöglicht es Git-Abhängigkeiten im Root oder in Subdependencies zu verbieten. Mit npm 12 wird die Nutzung von Git-Abhängigkeiten in der Standardkonfiguration unterbunden. Allow-remote ermöglicht die Deaktivierung von Abhängigkeiten im Root oder in Subdependencies, die von externen Servern geladen werden.
Pnpm bietet den Konfigurationsparameter blockExoticSubdeps: dieser blockiert Subdependencies, welche nicht aus der Registry geladen werden. Das bedeutet, Subdependencies, welche Git-Repositories oder ein Dateiarchiv referenzieren, können nicht mehr installiert werden. Im Root sind diese jedoch weiterhin zulässig. Seit Version 11 ist diese Option standardmäßig aktiviert.
Exakte Versionen speichern
Standardmäßig speichern Node-Paketmanager Paketversionen bei der Installation eines Paketes als Versionranges, so bedeutet etwa ^1.0.0, dass Fix und Minorversionen erlaubt sind. Das heißt, auch die Version 1.99.99 entspricht diesem Versionrange. Zum einfacheren Verständnis kann man den Package-Manager mit
--save-exact anweisen, die genaue Versionsnummer bei der Installation zu speichern.
Fazit
npm 12 und pnpm 11 bringen jede Menge neue Sicherheitsfeatures mit, die Schutz vor Supply-Chain-Angriffen bieten sollen. Besonders wichtig: Die Standardkonfigurationen aktivieren viele dieser Features bereits. Einzig die fehlende Konfiguration für min-release-age bei npm 12 sorgt für Handlungsbedarf. Die neuen Versionen der Paketmanager sorgen hoffentlich in Zukunft für ein sichereres Ökosystem.
