Kurz gesagt: npm-Lieferkettensicherheit jenseits des Schwachstellenscanners
Die Sicherheit der npm-Lieferkette ist die Praxis, sicherzustellen, dass jedes Paket, das Ihre JavaScript-Projekte installieren, legitim, unverändert und sicher ist. nicht nur frei von bekannten Schwachstellen.
- Die Lücke: Ein klassischer npm-Schwachstellenscanner gleicht Pakete mit CVE-Datenbanken ab. Ein schädliches Paket hat keine CVE-Nummer und besteht daher den Test.
- Der Beweis: Im März 2026 wurde axios, das wöchentlich über 100 Millionen Downloads verzeichnet, von einem gehackten Betreiberkonto für etwa drei Stunden zu einem Malware-Verbreitungskanal umfunktioniert.
- Der Einstiegspunkt: Die meisten npm-Angriffe erfolgen über Installationsskripte, die ausgeführt werden, sobald Sie den Befehl eingeben.
npm install. - Die Reparatur: Schädliches Verhalten soll bereits bei der Veröffentlichung von Paketen erkannt werden, nicht erst nach dem Auftreten einer CVE, und die Installationsabläufe sollen sicherer gestaltet werden.
Am 31. März 2026 führten Tausende von Entwicklern den gewöhnlichsten Befehl in JavaScript aus: npm installEinige von ihnen installierten eine neue Version von Axios, dem HTTP-Client, der in einem Großteil der Webanwendungen weltweit zum Einsatz kommt. Ihre Abhängigkeitsprüfungen verliefen erfolgreich. Ihre Builds wurden fehlerfrei ausgeführt. Und dennoch niste sich unbemerkt ein Remote-Access-Trojaner auf ihren Rechnern ein.
In dieser Geschichte ging es nicht um eine Sicherheitslücke. Genau deshalb haben so viele npm-Sicherheitsprogramme sie übersehen.
Was geschah mit Axios?
Der Angriff war simpel und geduldig. Laut … Die Selbstanalyse der Axios-EntwicklerZwei manipulierte Versionen, 1.14.1 und 0.30.4, wurden über das kompromittierte Konto des Hauptentwicklers veröffentlicht. Der Angreifer veränderte keine einzige Zeile des Axios-Codes. Er fügte lediglich eine neue Abhängigkeit hinzu. plain-crypto-js, das ein postinstall Skript, das eine Nutzlast der zweiten Stufe abrief.
Microsoft Threat Intelligence hat die Infrastruktur an Sapphire Sleet, einen nordkoreanischen Staatsakteur. Die manipulierten Versionen waren etwa drei Stunden lang aktiv, bevor npm sie entfernte. Für jegliche CI pipeline oder Laptop, der während dieses Zeitfensters installiert wurde, drei Stunden reichten aus.
Es handelte sich nicht um einen Einzelfall. Im September 2025 verbreitete sich der Shai-Hulud-Wurm über Hunderte von npm-Paketen, indem er Maintainer-Tokens stahl und sich selbst neu veröffentlichte. Andere Technik, gleiche Lehre: In npm wird Vertrauen automatisch vererbt, und Angreifer wissen das.
Warum Ihr npm-Schwachstellenscanner nichts gemeldet hat
Die meisten Teams behandeln die Sicherheit der npm-Lieferkette als ein Schwachstellenproblem. Sie führen einen npm-Schwachstellenscanner aus, der ihren Abhängigkeitsbaum mit Datenbanken bekannter Schwachstellen vergleicht, und beheben die gemeldeten Probleme. Diese Arbeit ist wichtig, beantwortet aber eine andere Frage.
| Abmessungen | anfälliges Paket | Schadpaket |
|---|---|---|
| Was es ist | Gültiger Code mit einem Fehler | Code, der Ihnen schaden soll |
| Ist eine CVE-Nummer vorhanden? | Normalerweise irgendwann | Fast nie |
| Wenn es gefährlich ist | Wenn die Schwachstelle erreichbar und ausgenutzt ist | Sobald es installiert ist |
| Was fängt es auf? | Eine Schwachstellendatenbank-Abfrage | Verhaltensanalyse des Pakets selbst |
| Typische benötigte Reaktionszeit | Tage bis Wochen | Minuten bis Stunden |
Eine Schwachstellendatenbank kann nur Informationen beschreiben, die bereits analysiert und katalogisiert wurden. Ein vor einer Stunde veröffentlichtes Schadprogramm ist nirgends verzeichnet. Daher meldet der Scanner keine Einträge, und diese werden als sicher interpretiert.
Das ist der zentrale Wandel in der Sicherheit der npm-Lieferkette: Die Frage lautet nicht mehr „Hat dieses Paket eine bekannte Schwachstelle?“, sondern „Tut dieses Paket etwas, was es nicht tun sollte?“
Vier Wege, wie Angreifer in Ihre node_modules gelangen
- Kontoübernahme. Man stiehlt die Zugangsdaten oder das Token eines Paketbetreuers und veröffentlicht eine manipulierte Version eines Pakets, dem die Nutzer bereits vertrauen. Dies ist die Vorgehensweise von Axios, und sie ist am schwersten zu erkennen, da der Paketname exakt übereinstimmt.
- Tippfehler. Veröffentlichen
axoisorreqeustsund dann darauf warten, dass ein Tippfehler passiert, dass jemand aus einem schlechten Tutorial kopiert und eingefügt hat oder dass ein KI-Programmierassistent den falschen Namen vorschlägt. - Abhängigkeitsverwirrung. Veröffentlichen Sie ein öffentliches Paket mit demselben Namen wie eines Ihrer internen Pakete. Wenn Ihre Registry-Konfiguration das öffentliche Paket bevorzugt, installieren Sie den Code des Angreifers.
- Skripte installieren. Der gemeinsame Nenner fast aller oben genannten Punkte: npm ermöglicht das Ausführen von Paketen.
preinstallundpostinstallSkripte werden automatisch ausgeführt, sodass Schadcode ausgeführt wird, bevor irgendjemand etwas importiert. CISA's Leitlinien zum Axios-Kompromiss empfiehlt die Einstellungignore-scripts=truefür vorcisAus diesem Grund.
Wie die Sicherheit der npm-Lieferkette in der Praxis aussieht
Mit einer einzigen Kontrollmaßnahme lassen sich nicht alle Angriffe abwehren. Mit einigen wenigen Gewohnheiten können Sie sich jedoch zu einem deutlich schwereren Ziel machen:
- Commit Ihre Sperrdatei und installieren Sie mit
npm ci. Bei den Builds sollte genau das installiert werden, was überprüft wurde, niemals das, was die Registry an diesem Morgen bereitgestellt hat. - Installationsskripte standardmäßig deaktivieren. Stelle den
ignore-scripts=trueund Skripte nur für die Pakete zulassen, die sie wirklich benötigen. - Begrenzen Sie Ihre internen Pakete. Nicht definierte interne Namen laden geradezu zu Verwirrung bei Abhängigkeiten ein.
- Herkunft prüfen. npm unterstützt Herkunftsangaben Diese Verknüpfungen verbinden ein veröffentlichtes Paket mit seinem Quellcode und dem Build-Prozess. Eine plötzliche Veröffentlichung ohne diese Verknüpfungen bei einem Projekt, das sie normalerweise verwendet, ist ein Warnsignal, das eine Automatisierung rechtfertigt.
- Kombinieren Sie Schwachstellenscans mit Malware-Erkennung. Verwenden Sie Ihren npm-Schwachstellenscanner weiterhin für bekannte Schwachstellen und fügen Sie eine Erkennungsfunktion hinzu, die analysiert, was neue Pakete tatsächlich tun.
Die fünfte Gewohnheit ist diejenige, die die meisten Teams vernachlässigen, und genau diese wurde durch den Axios-Angriff aufgedeckt.
Fangen Sie das schädliche Paket ab, bevor es einen Namen erhält.
Xygenis Malware-Frühwarnung (MEW) Das System scannt neue Pakete in öffentlichen Paketdatenbanken, einschließlich npm, sobald diese veröffentlicht werden, und analysiert deren Codeverhalten, anstatt auf eine bekannte Signatur zu warten. Wird ein Paket als problematisch eingestuft, werden betroffene Nutzer per E-Mail, Messenger oder über das Web benachrichtigt.hooksund das Paket befindet sich daher in Quarantäne. Sie können es an Ihrer Stelle stoppen. CI/CD guardrails.
Rundherum Xygenis open source security Es deckt die übrigen Schwachstellen ab, auf denen die vier oben genannten Angriffspfade basieren: Typosquatting, Abhängigkeitskonflikte, verdächtige Installationsskripte und nicht definierte interne npm-Komponenten. Außerdem werden bekannte Schwachstellen aus NVD-, OSV- und GitHub-Sicherheitswarnungen abgedeckt, priorisiert nach Erreichbarkeit, sodass Sie nur die tatsächlich ausnutzbaren Schwachstellen beheben können – mit automatischer Fehlerbehebung. pull requests für die Korrekturen.
MEW ist im kostenlosen Entwicklerpaket enthalten. Kostenlos starten und scannen Sie Ihre ersten npm-Projekte in wenigen Minuten.
FAQ
Was versteht man unter npm-Lieferkettensicherheit?
Die npm-Lieferkettensicherheit deckt alle Risiken ab, die durch die Pakete entstehen, von denen Ihre JavaScript-Projekte abhängen: bekannte Schwachstellen, schädliche Pakete, kompromittierte Entwicklerkonten, Typosquatting und Abhängigkeitskonflikte. Sie geht über das Scannen von Schwachstellen hinaus und stellt sicher, dass die installierten Pakete legitim sind.
Kann ein npm-Schwachstellenscanner Malware erkennen?
Normalerweise nicht. Ein herkömmlicher npm-Schwachstellenscanner prüft Pakete anhand von Datenbanken bekannter Schwachstellen. Ein neu veröffentlichtes, schädliches Paket hat keinen Datenbankeintrag und wird daher nicht geprüft, es sei denn, das Tool analysiert auch das Paketverhalten.
Is npm audit genug?
npm audit ist eine nützliche, kostenlose Basislinie für bekannte Schwachstellen. Sie erkennt keine neu veröffentlichte Malware, Typosquats oder Abhängigkeitskonflikte und gibt keine Auskunft darüber, ob eine anfällige Funktion tatsächlich von Ihrem Code aus erreichbar ist.
Woran erkenne ich, ob ein Paket schädlich ist?
Warnzeichen sind unter anderem Installationsskripte, die entfernten Code herunterladen oder ausführen, verschleierter Code, Netzwerkaufrufe, die nicht mit dem Zweck des Pakets in Zusammenhang stehen, eine neue Abhängigkeit, auf die das Quellcode-Repository nie verweist, und eine Veröffentlichung ohne die Herkunftsangaben, die das Projekt normalerweise veröffentlicht.
