Schnelle Antwort: Npm-Lieferkettenangriffe funktionieren, indem sie ein vertrauenswürdiges Wartungskonto oder ein CI/CD Dabei wird ein Token verwendet, um eine manipulierte Version eines Pakets zu veröffentlichen, dem Entwickler bereits vertrauen, und die Installationsskripte oder die Wurmlogik dieses Pakets den Rest erledigen zu lassen. Zwischen August 2025 und Mitte 2026 führte dieses Muster zur größten Welle von Angriffen auf die npm-Paketlieferkette in der Geschichte der Registry, einschließlich des Chalk/Debug-Hijackings. Shai-Hulud-Wurmund Schadsoftware von Nationalstaaten, die in einem Paket versteckt ist, das wöchentlich 100 Millionen Mal heruntergeladen wird. Die Lösung besteht nicht darin, den Code nach dem Herunterladen zu scannen. Sie besteht darin, schädliche Pakete abzufangen, bevor sie installiert werden, und sie zu überwachen. pipeline für das genaue Verhalten, das diese Angriffe gemeinsam haben.
Jede Installation ist ein Akt des Vertrauens, und Angreifer wissen das.
Ein Entwickler führt npm installierenHinter diesem einen Befehl verbirgt sich ein Abhängigkeitsbaum mit Hunderten, manchmal Tausenden von Paketen, die größtenteils von Personen geschrieben und gepflegt werden, die der Entwickler nie persönlich kennenlernen wird. Niemand prüft diesen Baum Zeile für Zeile. Niemand hat die Zeit dafür.
Dieses Vertrauen ist das Ziel. Für einen Angreifer ist es günstiger, einen npm-Maintainer mit 2.6 Milliarden wöchentlichen Downloads per Phishing anzugreifen, als eine Zero-Day-Schwachstelle in der Firewall eines Fortune-500-Unternehmens zu finden. Angriffe auf die npm-Lieferkette nutzen genau diese Asymmetrie aus, und die Angriffswelle von 2025/2026 zeigt, wie weit diese Schwachstelle bereits verbreitet ist: von von isoliertem Typosquatting bis hin zu sich selbst vermehrenden Würmern die ihre eigenen Schadsoftwarepakete schneller veröffentlichen, als ein Mensch reagieren kann.
Was zählt als npm-Lieferkettenangriff?
Ein npm-Lieferkettenangriff ist jeder Vorfall, bei dem ein Angreifer bösartigen Code in die npm-Distribution einfügt. pipeline anstatt in den Quellcode des Zielsystems einzudringen, wird die Schadsoftware als routinemäßiges Abhängigkeitsupdate getarnt. Der Einstiegspunkt ist üblicherweise einer von drei Dingen: gestohlene Zugangsdaten eines Entwicklers, gestohlene Veröffentlichungsdaten oder CI/CD Token oder ein kompromittierter Build pipeline Das Paket wird dazu verleitet, im Namen des Angreifers zu veröffentlichen. Da npm-Pakete transitive Abhängigkeiten automatisch einbinden, kann ein einzelnes kompromittiertes Paket Anwendungen erreichen, die es nie als direkte Abhängigkeit deklariert haben.
Zeitleiste: Die größten npm-Lieferkettenangriffe der Jahre 2025-2026
Das Muster hinter jedem Angriff auf die Lieferkette von npm-Paketen
Lässt man die Details außer Acht, so folgen fast alle oben genannten Vorfälle denselben vier Schritten:
- Kompromittiere eine Identität, nicht ein System. Ein durch Phishing gehackter Maintainer, ein durchgesickertes npm-Token, ein gestohlenes GitHub-PAT oder ein OIDC-Token, das von CI/CD Der Angreifer knackt nicht die Registry, sondern leiht sich den Schlüssel dazu.
- Veröffentlichen Sie unter einem Namen, dem Entwickler bereits vertrauen. Wenn der echte Paketname funktioniert, ist kein Typosquatting nötig. Genau das macht diese Angriffe so effektiv gegen automatisierte Updates. pipelines: Das Update sieht völlig legitim aus.
- Führe es aus, bevor es jemand bewertet. Bösartige Installationsskripte, verschleierte Nutzdaten oder im Hintergrund laufender Code, der nur unter bestimmten Bedingungen aktiviert wird, werden in diesem Moment ausgeführt. npm installieren läuft oft auf dem Laptop eines Entwicklers, lange bevor ein geplanter Sicherheitsscan es überhaupt entdecken würde.
- Beharren und sich zunehmend ausbreiten. Shai-Hulud und seine Nachfolger nutzen die gestohlenen Zugangsdaten, um automatisch das nächste manipulierte Paket zu veröffentlichen und so aus einer einzigen Kompromittierung eine Kettenreaktion im gesamten Abhängigkeitsgraphen auszulösen.
Warum die üblichen Verteidigungsstrategien versagen
Die meisten AppSec-Tools wurden entwickelt, um den bereits im Repository vorhandenen Inhalt zu analysieren: bekannte CVEs, statische Codemuster und Lizenzprobleme. Das ist zwar notwendig, kommt aber strukturell zu spät für diese Art von Angriff. Bis ein Scanner eine Abhängigkeit erkennt, kann das Installationsskript bereits auf dem Rechner des Entwicklers ausgeführt worden sein. Herkömmliche Antivirenprogramme und EDR-Lösungen überwachen das Betriebssystem, nicht die Paketdatenbanken, daher kennen sie eine „neue npm-Version“ nicht als Risikoeinheit. Und wie die Vorfälle bei TanStack und Red Hat zeigen, reichen selbst Build-Integritätsbescheinigungen wie … nicht aus. SLSA provenance Das hilft nicht, wenn der Angreifer die Identität, die die Signaturen signiert, rechtmäßig erlangt hat: Die Signatur ist gültig, das Paket ist trotzdem bösartig.
Die Lücke, die diese npm-Lieferkettenangriffe ausnutzen, liegt genau bei der Veröffentlichung und Installation, bevor eine Signatur für die Malware existiert und bevor das Paket irgendwo ausgeführt wurde, wo ein herkömmlicher Scanner suchen würde.
Wie man den nächsten npm-Lieferkettenangriff verhindern kann
Ein Teil davon ist Prozessdisziplin, die jedes Ingenieurteam heute schon anwenden kann:
- Pin-Abhängigkeiten und commit SperrdateienSo kann ein automatisches Update nicht unbemerkt eine gerade veröffentlichte, bösartige Version einspielen.
- Postinstallationsskripte deaktivieren oder in einer Sandbox ausführen Standardmäßig ist es bei den meisten Paketen nicht erforderlich, bei der Installation beliebigen Code auszuführen.
- Hardwaregestützte MFA für npm-Veröffentlichungskonten erzwingen, wodurch der genaue Phishing-Pfad geschlossen wurde, der die Konten von chalk, debug und Qix kompromittiert hatte.
- Zielfernrohr und Drehung CI/CD Token aggressivund behandeln Sie OIDC-Token im Runner-Speicher als schutzwürdige Anmeldeinformationen und nicht als Implementierungsdetail.
- Achten Sie auf das Entriegeln-Injizieren-Wiederverriegeln-Muster in CI/CD: eine Zweigschutzregel deaktiviert, ein commit Die Regel wurde innerhalb kürzester Zeit wieder aktiviert. Das ist ein wiederkehrendes Muster. pipelineKompromisse in der Lieferkette auf Ebene der Lieferkette.
Wo die Prozessdisziplin aufhört
Prozessdisziplin reduziert das Risiko. Sie erkennt schädliche Pakete nicht sofort nach ihrer Veröffentlichung und auch keine Würmer, die sich bereits so schnell im Netzwerk verbreiten, dass ein Mensch sie nicht mehr analysieren kann. Genau für diese Ebene ist die Lieferkettensicherheit von Xygeni konzipiert.
Xygenis MEW (Malware-Frühwarnung) Analysiert kontinuierlich neue Pakete, die auf npm, PyPI und Maven veröffentlicht werden, erkennt Malware, bevor eine Signatur existiert, und leitet bestätigte Bedrohungen zurück an Xygenis eigene Erkennungs-Engine. Abhängigkeitsfirewall Scannt npm, PyPI, Maven, NuGet und RubyGems in Echtzeit und blockiert schädliche Installationen, bevor diese den Rechner eines Entwicklers oder einen Build erreichen. CI/CD Anomalieerkennung Uhren pipelinegenau das Verhaltensmuster hinter Vorfällen wie dem TanStack-Kompromittierungsfall, einschließlich der Sequenz Entsperren-Injizieren-Wiederverriegeln, mit einem vollständigen Prüfprotokoll. Und weil Xygeni KI-gestützte Triage und Sanierung Dies gilt auch für Ergebnisse von Scannern von Drittanbietern; Teams müssen ihre bestehenden Tools nicht komplett ersetzen, um diese Lücke zu schließen.
FAQ: Angriffe auf die npm-Lieferkette
Was ist ein npm-Lieferkettenangriff?
Es handelt sich um einen Angriff, bei dem Schadcode über eine vertrauenswürdige npm-Abhängigkeit und nicht über den eigenen Code der Zielanwendung in diese gelangt, üblicherweise weil ein Angreifer das Konto eines Maintainers, ein Veröffentlichungstoken oder eine andere Instanz kompromittiert hat. CI/CD pipeline's Identität.
Was war der größte Angriff auf die Lieferkette von npm?
Gemessen am Ausmaß zählt der Chalk/Debug-Hijack vom September 2025 zu den größten: 18 Pakete mit insgesamt 2.6 Milliarden wöchentlichen Downloads wurden durch ein einziges kompromittiertes Maintainer-Konto kompromittiert. Technisch gesehen war Shai-Hulud jedoch der bedeutendere Wendepunkt, da es sich um den ersten sich selbst verbreitenden Wurm in der Geschichte von npm handelte.
Wie beginnt ein Angriff auf die Lieferkette eines npm-Pakets üblicherweise?
Fast immer mit einer gestohlenen Identität: ein durch Phishing manipulierter Administrator, ein durchgesickertes Veröffentlichungstoken oder ein gestohlener CI/CD Anmeldeinformationen wie ein OIDC-Token, die aus dem Speicher eines Runners abgerufen werden, anstatt eines technischen Einbruchs in npm selbst.
Können Antivirenprogramme oder EDR-Systeme einen npm-Lieferkettenangriff stoppen?
Nicht zuverlässig. EDR überwacht das Betriebssystem und kann keine Paketverwaltungssysteme verarbeiten, und Virenschutzprogramme arbeiten signaturbasiert, was bei Malware, die vor dem Vorhandensein einer Signatur veröffentlicht wurde, wirkungslos bleibt. Um diese Art von Angriffen zu stoppen, ist eine Überwachung bereits bei der Veröffentlichung und Installation erforderlich, nicht nur auf den Endgeräten.
Beeinflusst die SLSA provenance Oder kann eine Baubescheinigung dies verhindern?
Es beweist die pipeline Die Software selbst wurde während des Build-Prozesses nicht manipuliert. Dies beweist jedoch nicht, dass die Identität, die den Build ausgelöst hat, nicht kompromittiert wurde, wie die Vorfälle bei TanStack und Red Hat anhand gültiger Atteste, die an schädliche Pakete angehängt waren, gezeigt haben.
Wie kann ein Team ein schädliches npm-Paket erkennen, bevor es installiert wird?
Indem kontinuierlich Malware-Analysen vor der Signaturerstellung an neu veröffentlichten Paketen durchgeführt werden – genau das ist die Aufgabe eines Malware-Frühwarnsystems und einer Abhängigkeits-Firewall – anstatt sich ausschließlich auf nachträgliche Schwachstellenscans von bereits im Repository vorhandenem Code zu verlassen.
Wo soll ich anfangen
Die Angriffe auf die npm-Lieferkette nehmen nicht ab, und der Trend seit Shai-Hulud deutet eher auf mehr als auf weniger Automatisierung hin. Die Teams, die für die nächste Kampagne am besten gerüstet sind, sind diejenigen, die aufgehört haben, jede npm-Installation als Routinevorgang zu behandeln und stattdessen die Registry überwachen. pipelineund der Endpunkt als eine zusammenhängende Angriffsfläche.
Der Entwicklerplan von Xygeni umfasst MEW und Dependency Firewall-Abdeckung. Bis zu 25 Repositories können kostenlos verwaltet werden. Es bietet eine gute Übersicht über die bereits vorhandenen Abhängigkeiten in einem Abhängigkeitsbaum.
