Mehrere prominente Angriffe auf Open-Source-Software haben in den vergangenen Monaten die npm-Ökosysteme erschüttert. Amazon verknüpft die kompromittierten Pakete typo-crypto, debug, chalk und später auch axios mit dem Bedrohungsakteur Sapphire Sleet. Für Betreiber und Entwickler ist vor allem ein Muster relevant: Die Angriffe laufen nicht über „klassische“ Malware, sondern über den Vertrauensvorschuss, den Paketquellen ihren Nutzern bieten.
Was bedeutet das konkret für Teams, die Node.js-Anwendungen bauen, CI/CD-Pipelines betreiben oder Sicherheitskontrollen pflegen? Der Bericht zeigt, wie sich die Taktiken weiterentwickelt haben – und warum moderne Angriffsansätze immer schwerer allein mit statischen Prüfungen zu erkennen sind.
Amazon ordnet mehrere npm-Supply-Chain-Angriffe zu
Amazon stellt eine Verbindung zwischen mehreren hochaufmerksamkeitsstarken Supply-Chain-Kompromittierungen und einem Akteur her, der unter verschiedenen Namen geführt wird, unter anderem BlueNoroff und Stardust Chollima. Die Grundlage für diese Zuordnung ist laut Amazon nicht nur der direkte Inhalt einzelner Pakete, sondern eine Kombination aus beobachteten Verhaltensmustern (TTPs), der verwendeten Command-and-Control-Infrastruktur sowie weiteren operativen Ähnlichkeiten.
Die Einschätzung trägt dabei laut Bericht mittleres Vertrauen. Trotzdem ist die Stoßrichtung klar: Angreifer nutzen die breite Abhängigkeit in der npm-Welt, um aus einer scheinbar harmlosen Bibliothek in kurzer Zeit viele Folgeziele zu erreichen.
So verlief die Angriffskette über mehrere Pakete
Die Aktivitäten starteten laut Amazon im März 2025. Damals wurde das Paket typo-crypto kompromittiert, indem der Angreifer es in einen trojanisierten Zustand versetzte. Amazon bewertet diese Phase als eine Art Testumgebung für das Vorgehen.
Danach verschob sich der Schwerpunkt. Im September 2025 wurden die Pakete debug und chalk angegriffen. Diese beiden Bibliotheken sind weit verbreitet, und Amazon schätzt, dass innerhalb von zwei Stunden etwa 10% der Cloud-Umgebungen betroffen waren. Das zeigt, wie schnell sich ein Supply-Chain-Vorfall ausbreiten kann, sobald ein populäres Paket manipuliert wird.
Im März 2026 kam es schließlich zur Zielsetzung von axios, einem der am häufigsten genutzten npm-Pakete. Der Bericht nennt hierfür eine Größenordnung von über 100 Millionen Downloads pro Woche.
Warum die axios-Komponente besonders aufmerksam macht
Amazon weist darauf hin, dass die Vorfälle rund um axios bereits öffentlich bestimmten Akteursgruppen, die mit der DPRK in Verbindung gebracht werden, zugeschrieben wurden. Dennoch ordnet Amazon auch diese Episode in die frühere Sequenz von Paketkompromittierungen ein.
Für Security-Verantwortliche ist das relevant, weil es die Annahme stärkt, dass es sich nicht um isolierte Manipulationen handelt, sondern um eine zusammenhängende Kampagne mit wiederverwendeten Mustern und Infrastruktur.
Angreifer setzen auf Social Engineering statt „harte“ Einbruchstechniken
Laut Amazon verschaffte sich der Angreifer den Zugriff durch Social Engineering gegen Paketmaintainer. Anschließend veröffentlichte er maliziöse Updates, die automatisch an Nutzer weitergegeben wurden, die auf die Paketregistrierung vertrauten.
Genau hier liegt eine der größten Herausforderungen: Sobald ein kompromittiertes Paket im Ökosystem „richtig“ aussieht, kann es sich in bestehende Abhängigkeitsketten einschleusen – oft ohne dass die eigentliche Anwendungscodebasis etwas davon merkt.
Finanzielles Interesse: Ein Ziel, viele Folgeopfer
Amazon geht davon aus, dass die Angreifer finanzielle Motivation hatten. Der Ansatz: Populäre Pakete werden missbraucht, um indirekt Zugriff auf einen großen Pool nachgelagerter Opfer gleichzeitig zu gewinnen. Statt einzelne Organisationen nacheinander zu attackieren, wird ein „Multiplikator“ genutzt: Je größer die Verbreitung des betroffenen Pakets, desto größer die Reichweite der Downstream-Ziele.
Sechs Trends, die npm-Supply-Chain-Angriffe aktueller machen
Amazon nennt mehrere Entwicklungslinien, die sich aus den jüngsten Vorfällen ableiten lassen. Diese Trends helfen dabei zu verstehen, warum moderne Angriffe in der Praxis so schwer zu erkennen sind:
- Aufteilung bösartiger Funktionen: Schadcode kann über mehrere scheinbar legitime Pakete verteilt werden, sodass Signaturen weniger zielgenau greifen.
- Monatelanges Vertrauensaufbauen: Angreifer pflegen Projekte oder werden Contributors, bevor sie schließlich bösartige Elemente einbringen.
- Entkopplung vom Paketinhalt: Das schädliche Verhalten kann auf externe Skripte, Konfigurationsdateien oder später aktivierbare Server ausgelagert werden.
- Stärkere Verschlüsselung und mehrstufige Payloads: Schlüssel können zur Laufzeit oder über entfernte Quellen bereitgestellt werden, was statische Analysen erschwert.
- Umweltbewusstsein: Payloads werden nur dann ausgeführt, wenn bestimmte Bedingungen erkannt werden – etwa echte Entwickler- oder Produktionsumgebungen – um Sandboxes zu umgehen.
- „Slopsquatting“ mit KI-Hilfsmitteln: Angreifer registrieren Paketnamen, die durch KI-basierte Coding-Assistenten „halluziniert“ wurden, in der Hoffnung, dass Entwickler oder autonome Agents sie installieren.
Besonders brisant: Laut Amazon werden mehrere dieser Taktiken durch KI zugleich verbessert und vereinfacht. Das umfasst unter anderem Code- und Dokumentationsgenerierung sowie das Erstellen glaubwürdiger Maintainer-Identitäten.
Warum klassische Kontrollen allein nicht reichen
Selbst wenn Teams Alerts auf Ereignisse setzen, kann ein Teil der Angriffe „durchrutschen“. Im Bericht wird eine Einordnung genannt: Ein hoher Anteil erfolgreicher Angriffe wird zwar protokolliert, aber nur ein deutlich kleinerer Teil führt zu rechtzeitigen Alarmen. Ein wesentlicher Grund liegt darin, dass Supply-Chain-Angriffe häufig in normalen Entwicklungs- und Deploy-Prozessen stattfinden – und damit in einem „üblichen“ Aktivitätsbild verborgen sind.
Hinzu kommt: Wenn schädliches Verhalten erst zur Laufzeit greift, extern nachgeladen wird oder nur bei bestimmten Umgebungsmerkmalen startet, dann sehen SIEM- und EDR-Regeln oft zu spät oder gar nicht. Die Folge kann sein, dass Erkennung und Abwehr nicht mit dem tatsächlichen Angriffstempo Schritt halten.
Testen Sie Regeln und Erkennung gegen Simulationen
Der Bericht weist darauf hin, dass Testansätze auf mehreren Ebenen helfen können, blinde Flecken in Sicherheitskontrollen aufzudecken. Ziel ist, die Wirksamkeit von SIEM- und EDR-Regeln gegen angenäherte Angriffsszenarien zu prüfen, sodass weniger Vorfälle unbemerkt bleiben.
Für Organisationen heißt das praktisch: Prüfen Sie, ob Ihre Monitoring-Signale bei typischen Supply-Chain-Indikatoren tatsächlich greifen. Dazu gehören unter anderem auffällige Paket-Updates, ungewöhnliche Abhängigkeiten, ungewöhnliche Verhaltensmuster nach Deployment sowie Anzeichen für nachgeladene Komponenten.
Antwort aus der Community: Meldung, Zusammenarbeit und Investitionen
Amazon beschreibt eine mehrgleisige Reaktion. Dazu gehört die Weitergabe der Ergebnisse und relevanter Informationen an die Community. Außerdem arbeitet das Unternehmen mit OpenSSF und weiteren Partnern zusammen.
Darüber hinaus investiert Amazon in die Initiative Akrites. Deren Ziel ist es, kritische Open-Source-Software besser gegen Angriffe zu schützen, die durch KI-gestützte Methoden erleichtert werden.
Fazit: npm-Supply-Chain-Angriffe treffen den Kern der Softwarelieferkette
Die von Amazon beschriebenen Fälle machen deutlich, dass npm-Supply-Chain-Angriffe nicht nur ein theoretisches Risiko sind. Die Manipulation von Paketen wie debug, chalk und axios zeigt, wie schnell sich ein kompromittiertes Update verbreiten kann – und wie schwierig es sein kann, die Ursache ausschließlich aus dem Paketinhalt abzuleiten.
Wenn Sie Ihre Abhängigkeiten verantworten, sollten Sie zusätzlich zu sicheren Build- und Release-Prozessen auch die Erkennung und Reaktionsfähigkeit Ihrer Sicherheitskontrollen regelmäßig testen. Nur so verhindern Sie, dass Angriffe über die Softwarelieferkette im „Normalbetrieb“ verborgen bleiben.
