- Bei der Sicherheit von npm geht es heute nicht mehr nur um die Behebung einzelner CVEs, sondern um das Management von Lieferkettenrisiken über weitverzweigte Abhängigkeitsstrukturen hinweg.
- Tools wie npm audit, Sperrdateien, Dependabot und CI/CD-Prüfungen arbeiten zusammen, um anfällige oder veraltete Pakete zu erkennen und zu beheben.
- Reale Angriffe wie Browser-Interceptor-Malware und der Shai-Hulud-Wurm zeigen, wie kompromittierte npm-Pakete Anmeldeinformationen stehlen oder Pipelines sabotieren können.
- Durch die Kombination von automatisiertem Scannen, starkem Account- und Geheimnismanagement sowie sorgfältiger Paketauswahl wird die Wahrscheinlichkeit erfolgreicher npm-basierter Angriffe erheblich verringert.
Wer heute mit Node.js oder TypeScript entwickelt, steht auf einem riesigen Berg von npm-Abhängigkeiten, die er nicht selbst geschrieben hat und wahrscheinlich nie vollständig lesen wird. Das ist zwar unglaublich praktisch, um schnell neue Funktionen bereitzustellen, öffnet aber gleichzeitig eine riesige Angriffsfläche für Bedrohungen der Lieferkette, den Diebstahl von Zugangsdaten und das Einschleusen subtiler Hintertüren in Anwendungen oder CI/CD-Pipelines.
Moderne npm-Sicherheit beschränkt sich nicht mehr nur auf die Frage: „Gibt es bekannte CVEs in meinen Paketen?“ – es geht um Abwehr von Phishing-Kampagnen, die die Accounts von Account-Managern kapern.Würmer, die infizierte Versionen automatisch veröffentlichen, und bösartige Bibliotheken, die versuchen, die Daten eines Entwicklers zu löschen home Verzeichnisse anlegen oder Cloud-Zugangsdaten stehlen. In diesem Leitfaden erklären wir, wie das geht. npm-Sicherheitsprüfung funktioniert, wie Sie Ihre Arbeitsabläufe mit Tools wie npm audit, Dependabot, SAST/SCA-Scanner und CI/CD-Prüfungen sowie was Sie als Entwickler realistischerweise tun können, wenn Sie befürchten, dass „diese coole kleine Bibliothek Malware sein könnte“.
Warum die Sicherheit von npm-Abhängigkeiten so wichtig ist
Jedes Mal, wenn du läufst npm installSie importieren also Code von Drittanbietern in Ihr Projekt und effektiv seinen Autoren vertrauen mit einem Teil Ihrer Angriffsfläche. In Node.js kann diese Vertrauenskette überraschend tiefgreifend sein: Eine einzige Abhängigkeit auf oberster Ebene kann Hunderte von transitiven Paketen einbinden, die Sie nie direkt ausgewählt haben.
Schwache oder vernachlässigte Abhängigkeiten können zu klassischen Sicherheitsproblemen wie Injection-Angriffen, Denial-of-Service-Angriffen (DoS), Rechteausweitung oder Datenexfiltration führen. Selbst ein kleiner Fehler in einer Low-Level-Anwendung – einem HTTP-Client, einem Farbparser oder einem YAML-Loader – kann weitreichende Folgen haben, wenn er in gängigen Frameworks und Tools implementiert ist.
Neben den herkömmlichen Schwachstellen muss sich das Ökosystem nun auch mit böswilligem Verhalten auseinandersetzen: Pakete, die gezielt entwickelt wurden, um Geheimnisse zu stehlen , Kryptomining-Code einzuschleusen oder CI/CD-Pipelines zu kompromittieren. Dies sind keine theoretischen Risiken; zahlreiche reale Vorfälle haben gezeigt, dass Angreifer es auf die Konten von Paketbetreuern abgesehen haben und anschließend vertrauenswürdige Pakete für ihre Zwecke missbrauchen.
Die regelmäßige Überprüfung und Aktualisierung von Abhängigkeiten ist daher keine optionale Pflegemaßnahme, sondern ein zentraler Bestandteil der Wartung jedes ernsthaften Node.js- oder TypeScript-Projekts. Nur durch regelmäßige Sicherheitsüberprüfungen, sowohl automatisiert als auch manuell, lässt sich das Risiko durch Drittanbietercode auf ein akzeptables Maß reduzieren.
npm audit verstehen und was es tatsächlich prüft
npm audit ist der integrierte Befehl, der den Abhängigkeitsbaum Ihres Projekts anhand einer Datenbank bekannter Schwachstellen überprüft und einen Sicherheitsbericht erstellt. Wenn Sie ihn im Stammverzeichnis Ihres Projekts ausführen, untersucht npm Ihre Abhängigkeiten. package.json und Sperrdatei, erstellt den vollständigen Abhängigkeitsgraphen und gleicht jede Version mit den Empfehlungen ab.
Der Prüfbericht umfasst sowohl direkte als auch indirekte Abhängigkeiten (die von Ihnen selbst aufgeführten Pakete sowie Abhängigkeiten von Abhängigkeiten). Für jedes Problem werden das betroffene Paket, eine Zusammenfassung der Sicherheitslücke, deren Schweregrad (niedrig, mittel, hoch, kritisch) und der Versionsbereich, der die Korrektur enthält, aufgeführt.
Aus Sicht des Arbeitsablaufs, npm audit kann interaktiv genutzt werden von Entwicklern und nicht-interaktiv in CI/CD-Pipelines. In Pipelines kann man sogar erreichen, dass der Build nur dann fehlschlägt, wenn Schwachstellen einen bestimmten Schweregrad überschreiten, indem man Flags wie beispielsweise verwendet. --audit-level.
Das Tool gehört zur umfassenderen Familie der Software Composition Analysis (SCA) : Es konzentriert sich auf bekannte Probleme in Open-Source-Komponenten anstatt auf Fehler im eigenen Code. Daher eignet es sich hervorragend zum Aufspüren veralteter oder anfälliger Bibliotheken, erkennt aber nicht auf magische Weise brandneue Schadsoftware, die erst gestern unter einem noch nie dagewesenen Paketnamen veröffentlicht wurde.
Wie man npm audit ausführt und die Ergebnisse interpretiert
Um eine grundlegende Sicherheitsprüfung durchzuführen, öffnen Sie ein Terminal im Projektverzeichnis (wo package.json Leben) und laufen npm auditNach einer kurzen Abhängigkeitsanalyse gibt npm eine Tabelle mit Problemen aus, gruppiert nach Schweregrad, zusammen mit Vorschlägen zur Behebung, wie z. B. einem Upgrade auf eine gepatchte Version.
Die Prüfergebnisse enthalten typischerweise den Paketnamen, die installierte Version, die Beschreibung der Schwachstelle und deren Schweregrad (niedrig, mittel, hoch, kritisch) sowie die Pfade, die zeigen, wo im Abhängigkeitsbaum das Paket verwendet wird, und eine empfohlene korrigierte Version oder einen empfohlenen Versionsbereich. Betrachten Sie dies wie eine priorisierte Aufgabenliste: Beginnen Sie mit kritischen und hoch priorisierten Schwachstellen und arbeiten Sie sich dann zu den niedriger priorisierten vor.
Wenn Sie die Ergebnisse in andere Tools einlesen oder für später speichern möchten, können Sie die JSON-Ausgabe anfordern über npm audit --jsonDas ist besonders praktisch bei der Integration mit benutzerdefinierten Dashboards, Ticketsystemen oder Sicherheitsorchestrierungsplattformen.
In CI/CD-Pipelines konfigurieren viele Teams die Pipeline so, dass sie ausgeführt wird npm audit --json Direkt nach der Installation der Abhängigkeiten wird das Ergebnis analysiert und der Build fehlgeschlagen, falls eine Sicherheitslücke oberhalb eines festgelegten Schweregrades vorhanden ist. Externe Hilfsfunktionen wie audit-ci Diese Logik kann für Sie kapseln und Ihnen komfortable Optionen bieten, um Builds abzubrechen, wenn Schwellenwerte überschritten werden.
Behebung von Sicherheitslücken mit npm audit fix
Sobald npm audit Bei Flaggenproblemen ist Ihre erste Verteidigungslinie npm audit fix, das versucht, anfällige Abhängigkeiten automatisch auf die nächstliegenden sicheren Versionen zu aktualisieren. Im Hintergrund wird der Code umgeschrieben. package-lock.json (und package.json (sofern zutreffend) Pakete innerhalb kompatibler Versionsbereiche aktualisieren.
Diese automatische Behebung funktioniert gut bei vielen leichten und mittelschweren Problemen und sogar bei einigen schwerwiegenderen Problemen, deren Lösung ein kleineres Update oder ein Patch ist. Es ist eine schnelle Lösung, die oft einen Großteil des Problemrückstands mit minimalem Aufwand beseitigt.
Nicht jede Sicherheitslücke lässt sich durch ein automatisches Upgrade sicher beheben; manche erfordern größere Versionsänderungen, die Ihren Code oder andere Abhängigkeiten beeinträchtigen können. Genau da setzt das Problem an. npm audit fix --force Hier kommt es darauf an: Es erzwingt Aktualisierungen selbst bei grundlegenden Änderungen, aber man sollte es mit Vorsicht einsetzen und anschließend immer gründlich testen.
Bevor Sie in wichtigen Projekten die Option „Erzwingen“ anwenden, sollten Sie Ihre Sperrdatei sichern und eine gute Testabdeckung gewährleisten. Ein erzwungenes Upgrade kann Verhaltensänderungen oder Regressionen hervorrufen, die schwerer zu finden sind, wenn Sie keine Vergleichsbasis haben.
Sperrdateien, npm CI und deterministische Installationen
Das package-lock.json Datei (oder yarn.lock/pnpm-lock.yaml (für andere Manager) ist aus Sicherheitsgründen unerlässlich, da es die exakten Versionen aller von Ihrem Projekt verwendeten Abhängigkeiten festlegt. Ohne diese Einstellung würde jede Abhängigkeit nicht korrekt erkannt. npm install Es können leicht unterschiedliche kompatible Versionen verwendet werden, was die Builds nicht deterministisch macht und die Überprüfung erschwert.
Sie sollten Bearbeitungen vermeiden. package-lock.json Manuelles Hinzufügen und stattdessen npm die Verwaltung überlassen, wenn Sie Abhängigkeiten hinzufügen, entfernen oder aktualisieren. Beim Einchecken von Code sollten Sie immer beides angeben. package.json und die Sperrdatei, damit alle – und Ihre CI/CD-Pipeline – die gleichen Versionen installieren.
In automatisierten Umgebungen bevorzugen npm ci gegenüber npm install weil npm ci Die Sperrdatei dient als strikter Vertrag, und die Ausführung wird verweigert, wenn sie nicht mit den deklarierten Abhängigkeiten übereinstimmt. Dies führt zu schnelleren und vollständig reproduzierbaren Installationen – genau das, was man in CI-Umgebungen benötigt.
Aus Sicht der Lieferkettensicherheit bedeutet das Sperren und Reproduzieren von Installationen, dass Sie genau wissen, welche Versionen für einen bestimmten Build verwendet wurden. Dies ist entscheidend, um zu untersuchen, ob eine schädliche Version in Ihre Pipeline gelangt ist. Bei Bedarf können Sie Builds mithilfe historischer Sperrdateien wiederholen, um festzustellen, ob eine anfällige oder mit einer Hintertür versehene Version im Einsatz war.
Automatisierte Updates mit Dependabot, Renovate und npm-Tools
Die manuelle Nachverfolgung veralteter oder anfälliger Pakete in vielen Repositories wird schnell unübersichtlich. Deshalb ist die Automatisierung durch Tools wie Dependabot oder Renovate so wertvoll. Diese Dienste überwachen Ihre Abhängigkeiten und öffnen Pull Requests, sobald neue Versionen oder Sicherheitskorrekturen verfügbar sind.
Der Dependabot von GitHub wird beispielsweise über einen konfiguriert .github/dependabot.yml Eine Datei, die festlegt, welche Ökosysteme überwacht werden sollen, die Aktualisierungshäufigkeit und die Zielbranches. Wenn ein anfälliges oder veraltetes npm-Paket erkannt wird, wird ein Pull Request zur Aktualisierung erstellt. package.json und package-lock.json, oft mit Links zu Warnhinweisen.
Gepaart mit npm auditSo entsteht ein effektiver Feedback-Kreislauf: Das Audit identifiziert Probleme, und Dependabot (oder Renovate) schlägt kontinuierlich Verbesserungen zur Behebung dieser Probleme vor. Ihre Aufgabe beschränkt sich dann auf die Überprüfung und das Testen dieser Pull Requests, anstatt jede einzelne Versionsänderung manuell zu suchen.
Über die Automatisierung hinaus bietet npm selbst Hilfsbefehle wie zum Beispiel npm outdated um Pakete mit neueren Versionen aufzulisten und npm update Um innerhalb der zulässigen Versionsbereiche zu aktualisieren, sollten Sie regelmäßig Upgrades durchführen. Dadurch verringert sich das Risiko, dass Sie den Anschluss verlieren und mehrere Hauptversionen auf einmal überspringen müssen.
Sicherheitsprüfungen in CI/CD-Pipelines durchführen
Eine sichere npm-Konfiguration endet nicht auf Ihrem Laptop; Ihre CI/CD-Pipelines müssen ebenfalls Sicherheitsprüfungen durchführen, um zu verhindern, dass anfälliger oder schädlicher Code in die Produktionsumgebung gelangt. Jede Phase – Quellcode, Build, Test, Deployment – sollte über entsprechende Kontrollmechanismen verfügen.
Es ist üblich zu laufen npm audit automatisch während der Build- oder Vorbereitungsphase, oft mit dem --json Dieses Kennzeichen dient der einfacheren Integration mit Überwachungstools. Wenn der Scan Schwachstellen oberhalb Ihres Risikoschwellenwerts erkennt, kann die Pipeline fehlschlagen und die Veröffentlichung blockieren.
Fortschrittliche Tools wie Snyk können in CI/CD als Sicherheitswächter fungieren, indem sie Abhängigkeiten scannen und Builds bei schwerwiegenden oder kritischen Problemen abbrechen. In Kombination mit Qualitätsanalysetools wie SonarQube oder SonarCloud erhalten Sie ein umfassenderes Bild der Codequalität, der Sicherheitsrisiken und der technischen Schulden.
Während der Entwicklung werden statische Analysetools wie ESLint mit Plugins wie eslint-plugin-security und eslint-plugin-node Sie hilft Ihnen, unsichere Muster frühzeitig in Ihrem eigenen Code zu erkennen. Dies ergänzt die Abhängigkeitsprüfung, die sich auf Drittanbieterkomponenten anstatt auf Ihre Geschäftslogik konzentriert.
Absicherung von CI/CD-Pipelines über npm-Audit hinaus
Automatisierte Scans sind zwar leistungsstark, doch eine sichere Pipeline benötigt auch ein solides Geheimnismanagement, robuste Zugriffskontrolle und eine gute Repository-Pflege. Falsch konfigurierte Geheimnisse oder zu permissive Rollen können aus einer kleineren Sicherheitslücke einen schwerwiegenden Vorfall machen.
Verwenden Sie spezielle Geheimnismanager wie HashiCorp Vault oder AWS Secrets Manager, anstatt Token oder Schlüssel in Konfigurationsdateien oder Umgebungsvariablen einzubetten, die in die Versionskontrolle eingecheckt werden. Dadurch verringert sich das Risiko, dass ein Angreifer oder auch nur ein neugieriger Mitwirkender auf sensible Daten in Ihrem Repository stößt.
Rollenbasierte Zugriffskontrolle (RBAC) nach dem Prinzip der minimalen Berechtigungen ist für GitHub, npm und jede CI/CD-Plattform unerlässlich. Entwickler und Servicekonten sollten nur die unbedingt notwendigen Berechtigungen besitzen – nicht mehr.
Pre-Commit-Hooks und Tools zum Scannen geheimer Daten verhindern, dass API-Schlüssel, Token oder Passwörter überhaupt erst in Ihre Repositories gelangen. In Kombination mit strukturierten GitOps-Workflows und geschützten Branches bieten sie eine lückenlose Nachverfolgung und reduzieren das Risiko, dass ungeprüfte Änderungen zusammengeführt werden.
Benachrichtigungen Ihrer Sicherheitstools sollten in Echtzeitkanäle wie Slack, Microsoft Teams oder E-Mail integriert werden, jedoch sorgfältig abgestimmt, damit Ihr Team nicht mit irrelevanten Warnmeldungen überlastet wird. Die Priorisierung nach Schweregrad und Kontext lenkt die Aufmerksamkeit auf das Wesentliche.
Reale npm-Lieferkettenangriffe und was wir daraus lernen
In den letzten Jahren kam es bei npm zu mehreren aufsehenerregenden Lieferkettenvorfällen, bei denen Angreifer nicht einzelne Anwendungen, sondern die Entwickler oder Pakete ins Visier nahmen. Diese Angriffe verdeutlichen, wie sich ein einziges kompromittiertes Konto auf Millionen von nachgelagerten Installationen auswirken kann.
In einer Kampagne erhielt ein bekannter npm-Maintainer eine sorgfältig gestaltete Phishing-E-Mail von einer Domain, die der offiziellen npm-Website täuschend ähnlich sah. Die Nachricht drohte mit der Sperrung des Kontos, falls die Zwei-Faktor-Authentifizierung nicht „aktualisiert“ würde, und lockte das Opfer auf eine gefälschte Anmeldeseite, die die Zugangsdaten abfing.
Nachdem der Angreifer die Kontrolle über das npm-Konto des Entwicklers erlangt hatte, verbreitete er manipulierte Versionen von 18 extrem populären Paketen mit Milliarden von wöchentlichen Downloads. Da diese Pakete tief in die Abhängigkeitsstruktur des JavaScript-Ökosystems eingebunden waren, war das potenzielle Schadensausmaß enorm.
Der eingeschleuste Code verhielt sich wie ein browserseitiger Interceptor, der auf Kryptowährungs- und Web3-Aktivitäten abzielte: Er hakte sich in Browser-APIs ein, wie zum Beispiel fetch, XMLHttpRequest und Wallet-Schnittstellen wie window.ethereum oder Solana Wallet-APIs. Es durchsuchte Netzwerkantworten und Transaktionsnutzdaten nach allem, was wie eine Kryptoadresse oder -überweisung aussah.
Sobald die Schadsoftware eine Transaktion erkannte, ersetzte sie die legitime Empfängeradresse durch eine vom Angreifer kontrollierte Adresse. Dabei wählte sie häufig ähnlich aussehende Zeichenketten, um keinen Verdacht zu erregen. In vielen Fällen schien die Benutzeroberfläche weiterhin die „korrekte“ Adresse anzuzeigen, obwohl die zugrundeliegenden signierten Daten bereits so verändert worden waren, dass die Gelder an den Angreifer flossen.
Der Schadcode war stark verschleiert, mit Variablen wie _0x... und große, kodierte Zeichenkettenarrays, die zur Laufzeit dekodiert wurden, und manchmal wurden gefälschte Erfolgsmeldungen zurückgegeben, um zu verhindern, dass die Anwendung einen Fehler bemerkte. Nur bestimmte Apps waren tatsächlich angreifbar – insbesondere solche, die mit Wallets oder Kryptodiensten interagierten und die betroffenen Versionen innerhalb des kurzen Zeitfensters für die Kompromittierung installierten.
Lehren aus diesem Browser-Interceptor-Vorfall
Eine wichtige Lehre daraus ist, dass Entwickler bereit sein sollten, bei Bekanntwerden einer Paketkompromittierung schnell auf bekannte, sichere Versionen zurückzugreifen. Selbst wenn die Registry schädliche Versionen entfernt, können Ihre Sperrdateien und Caches weiterhin darauf verweisen, bis Sie explizit ein Downgrade oder Upgrade durchführen.
Eine gründliche Inspektion von package.json und package-lock.json (oder yarn.lockEs ist unerlässlich zu überprüfen, ob Ihr Projekt jemals die schädlichen Versionen installiert hat. Hier erweisen sich deterministische Installationen und versionsgebundene Sperrdateien als äußerst hilfreich und erleichtern die forensische Arbeit erheblich.
Wenn Ihre Anwendung mit Krypto-Wallets oder Web3-APIs interagiert, sollten Sie die Transaktionsprotokolle sorgfältig auf ungewöhnliche Zieladressen oder unerwartete Genehmigungen in dem Zeitraum überwachen, in dem kompromittierte Pakete vorhanden waren. Eine frühzeitige Erkennung kann den finanziellen Schaden begrenzen und helfen, betroffene Benutzer zu identifizieren.
Die Erhöhung der Kontosicherheit durch Zwei-Faktor-Authentifizierung, idealerweise über Hardware-Schlüssel, ist für npm- und GitHub-Konten unerlässlich – insbesondere für die Betreuer populärer Pakete. Seien Sie dennoch stets skeptisch gegenüber E-Mails, die Sie auffordern, auf einen Link zu klicken, um Ihre Zugangsdaten zu „aktualisieren“. Rufen Sie stattdessen direkt die offizielle Website auf und prüfen Sie dort auf Warnmeldungen.
Organisationen, die kommerzielle SCA- und SBOM-Tools einsetzen, können ihre Bestände häufig anhand von Paketnamen und Versionen abfragen, um alle Systeme und Anwendungen zu finden, die von einer kompromittierten Bibliothek abhängen. Diese Transparenz verkürzt die Reaktionszeiten bei Lieferkettenvorfällen erheblich.
Der Shai-Hulud-Wurm: selbstreplizierende npm-Malware
Eine weitere bemerkenswerte Kampagne, die sogenannte Shai-Hulud-Kampagne , trieb die Angriffe auf die npm-Lieferkette auf die Spitze, indem sie sich wie ein sich selbst replizierender Wurm über Pakete und Entwicklungsumgebungen hinweg verhielt. Sie nutzte npm-Installationsskripte aus, um schädlichen Code auszuführen, sobald eine kompromittierte Version installiert war.
Die Malware durchsuchte die Umgebung nach sensiblen Anmeldeinformationen, einschließlich .npmrc Dateien mit npm-Tokens, persönlichen GitHub-Zugriffstokens, SSH-Schlüsseln und Cloud-Anbieter-API-Schlüsseln für AWS, GCP und Azure. Alles, was es fand, wurde exfiltriert. zur vom Angreifer kontrollierten Infrastruktur.
Mithilfe gestohlener npm-Tokens authentifizierte sich der Wurm als kompromittierte Paketbetreuer, listete weitere von ihnen verwaltete Pakete auf, injizierte seine Schadsoftware und veröffentlichte anschließend neue, bösartige Versionen. Diese Automatisierung ermöglichte eine schnelle Verbreitung, ohne dass der Angreifer jedes Paket manuell bearbeiten musste.
In vielen Fällen wurden die gestohlenen Geheimnisse in neu erstellten öffentlichen GitHub-Repositories unter dem Konto des Opfers veröffentlicht, mit Namen oder Beschreibungen, die auf Shai-Hulud Bezug nahmen. Dadurch wurde das Problem noch verschärft, da sensible Daten für jeden zugänglich waren, der zufällig auf diese Repositories stieß.
Sicherheitsforscher entdeckten verräterische Anzeichen (darunter merkwürdige Kommentare und sogar Emojis), die darauf hindeuten, dass Teile der schädlichen Bash-Skripte mithilfe großer Sprachmodelle generiert wurden. Dies ist ein drastisches Beispiel dafür, wie generative KI missbraucht werden kann, um die Entwicklung von Angriffswerkzeugen zu beschleunigen.
Shai-Hulud 2.0: Sabotage vor der Installation und destruktive Rückfallmechanismen
Eine spätere Welle, Shai-Hulud 2.0 genannt, änderte ihre Taktik und führte die Skripte während der Vorinstallationsphase anstatt nach der Installation aus, wodurch ihre Reichweite auf Entwicklerrechnern und CI/CD-Servern erheblich erweitert wurde. Vorinstallationsskripte werden noch früher im Lebenszyklus ausgeführt und können auf mehr Systemen aktiviert werden.
Einer der alarmierendsten Aspekte dieser Variante war ein Ausweichmechanismus: Wenn es der Schadsoftware nicht gelang, nützliche Zugangsdaten zu stehlen oder einen Kommunikationskanal herzustellen, versuchte sie destruktives Verhalten wie beispielsweise das Opfer abwischen home VerzeichnisDies geschah durch Überschreiben und sicheres Löschen aller beschreibbaren Dateien, die dem aktuellen Benutzer in diesem Verzeichnis gehörten.
Die Nutzlast war als hilfreiche Bun-Installationsskripte getarnt, wie zum Beispiel setup_bun.js und ein riesiges, stark verschleiertes bun_environment.js Die Datei war größer als 9 MB. Um keine Aufmerksamkeit zu erregen, wurde die Hauptlogik in einen Hintergrundprozess ausgegliedert, sodass die ursprüngliche Installation scheinbar normal abgeschlossen wurde.
Die im Rahmen dieser Kampagne gesammelten Zugangsdaten und Geheimnisse wurden erneut nach GitHub exfiltriert, diesmal in Repositories mit der Bezeichnung „Sha1-Hulud: The Second Coming“. Die Malware versuchte, sich durch die Erstellung von GitHub Actions-Workflows wie beispielsweise … dauerhaft einzunisten. discussion.yamlDiese Arbeitsabläufe registrierten infizierte Rechner als selbstgehostete Runner, wodurch Angreifer beliebige Befehle auslösen konnten, indem sie einfach Diskussionen eröffneten.
Das Ausmaß war enorm und betraf Zehntausende von Repositories sowie mehr als 25 schädliche Repositories auf Hunderten von GitHub-Konten, darunter auch beliebte Bibliotheken wie @ctrl/tinycolor mit Millionen von Downloads pro Woche. Da das Ziel auch den Diebstahl von Zugangsdaten für Cloud-Plattformen umfasste, könnten die Folgen von Datendiebstahl und Ransomware bis hin zu Kryptomining und weitreichenden Dienstausfällen reichen.
Sofortige Abwehrmaßnahmen gegen npm-Lieferkettenwürmer
Bei Angriffen wie dem Shai-Hulud-Angriff empfehlen Incident-Responder, alle Zugangsdaten von Entwicklern umgehend zu erneuern – npm-Tokens, GitHub-PATs, SSH-Schlüssel und alle Cloud-API-Schlüssel, die auf Entwicklerrechnern oder Build-Servern verwendet werden. Gehen Sie davon aus, dass alle Daten, die sich auf einer kompromittierten Workstation befinden, möglicherweise offengelegt wurden.
Eine vollständige Abhängigkeitsprüfung aller Projekte ist unerlässlich; hierfür können Tools wie beispielsweise … verwendet werden. npm audit, SBOM-Inventare oder kommerzielle SCA-Plattformen, um jegliche Verwendung der betroffenen Paketnamen und -versionen zu ermitteln. Sperrdateien (package-lock.json, yarn.lock) die tatsächliche Realität dessen zu ermitteln, was tatsächlich installiert wurde.
Entwickler sollten ihre GitHub-Konten auf ungewöhnliche öffentliche Repositories (insbesondere solche mit dem Namen Shai-Hulud), verdächtige Commits oder unerwartete Änderungen an GitHub Actions-Workflows überprüfen, die möglicherweise nicht autorisierte Runner registriert haben. Jegliche Anomalien sollten als Anzeichen einer Kompromittierung behandelt werden.
Die Durchsetzung der Multi-Faktor-Authentifizierung für alle Entwicklerkonten – nach Möglichkeit mit phishingresistenten Methoden – ist ein weiterer unabdingbarer Schritt. Sie beseitigt zwar nicht das Risiko, erhöht aber die Hürden für Angreifer, die versuchen, Zugangsdaten zu stehlen.
Organisationen, die fortschrittliche Plattformen zur Bedrohungsanalyse nutzen, können auch benutzerdefinierte Abfragen verwenden, um nach bekannten Indikatoren wie Anrufen bei bestimmten Diensten zu suchen. webhook.site URLs, Vorhandensein von Dateien wie shai-hulud-workflow.yml oder verdächtig groß bun_environment.js Dateien, die auf Entwicklerrechnern geschrieben werden. Eine frühzeitige Erkennung durch Telemetriedaten kann die Verweildauer drastisch reduzieren.
Wie die Anbieter reagieren: Erkennungs- und Präventionsfähigkeiten
Sicherheitsanbieter aktualisieren ihre Produkte, um npm-basierte Lieferkettenangriffe sowohl auf Endgeräten als auch im Netzwerk zu erkennen und zu blockieren. Dies umfasst Signaturen für bekannte Schadsoftware und Verhaltensmodelle für ungewöhnliche Prozess- oder Dateiaktivitäten während der Installation.
Fortschrittliche Sandboxing- und Malware-Analyse-Dienste können verschleierte JavaScript-Payloads, wie sie beispielsweise in den Shai-Hulud-Kampagnen verwendet wurden, erkennen. Wenn diese Tools verdächtige Skripte vor oder nach der Installation entdecken, die versuchen, Anmeldeinformationen abzufangen oder Dateien zu zerstören, geben sie Warnungen aus oder blockieren die Ausführung.
Firewalls der nächsten Generation mit fortschrittlicher Bedrohungsabwehr und URL-Filterung können helfen, indem sie den Zugriff auf schädliche Domains blockieren, die beim Phishing oder Datenexfiltration verwendet werden – beispielsweise gefälschte npm-Support-Domains oder bestimmte webhook.site Endpunkte sind fest in die Malware einprogrammiert. Durch die Einstufung dieser URLs als schädlich wird verhindert, dass die Nutzlast gestohlene Daten erfolgreich sendet..
Endpoint Detection and Response (EDR/XDR)-Agenten tragen dazu bei, indem sie das Prozessverhalten, die Skriptausführung und die Erstellung ungewöhnlicher Dateien (wie z. B. riesige Dateien) überwachen. bun_environment.js Dateien) und verdächtige Befehlszeilen. Sie können sowohl bekannte Hashes als auch bisher unbekannte Varianten anhand von Verhaltensregeln stoppen.
Cloud-native Anwendungssicherheitsplattformen integrieren zunehmend Funktionen mit Fokus auf die Lieferkette, wie z. B. Echtzeit-SBOM-Transparenz, Risikobewertung für Open-Source-Komponenten und CI/CD-Fehlkonfigurationsprüfungen (fehlende Sperrdateien, unsichere Konfigurationen). npm install Nutzung, Git-basierte Abhängigkeiten ohne festgelegte Commit-Hashes, ungenutzte Abhängigkeiten, die die Angriffsfläche vergrößern). Diese Kontrollen erschweren es, dass bösartige oder ungeprüfte Paketversionen in Produktions-Builds gelangen.
Praktische Gewohnheiten für Entwickler, die sich Sorgen um bösartige npm-Pakete machen
Wenn Sie neu in der Welt von JavaScript/TypeScript sind und sich bei der Installation von npm-Paketen jedes Mal unsicher fühlen, sind Sie nicht allein. Es gibt jedoch konkrete Gewohnheiten, die Sie sich aneignen können, um das Risiko zu minimieren, ohne Ihre Produktivität einzuschränken. Betrachten Sie sie als eine Art persönliche Sicherheitscheckliste.
Bevorzugen Sie zunächst etablierte Pakete mit einer soliden Wartungshistorie , einem aktiven Issue-Tracker und breiter Verbreitung, insbesondere für Kerninfrastruktur wie HTTP-Clients, Logging oder Kryptografie. Das garantiert zwar keine Sicherheit, bedeutet aber in der Regel, dass der Code häufiger geprüft wird und Fehler schneller erkannt werden.
Bei kleinen oder wenig bekannten Paketen (insbesondere solchen mit kaum Downloads) sollten Sie genauer hinschauen: Prüfen Sie die npm-Seite, die Repository-Links, das Datum der letzten Veröffentlichung und ob der/die Verantwortliche eindeutig identifizierbar ist. Seien Sie vorsichtig, wenn das npm-Paket auf ein GitHub-Repository verlinkt, das nicht den veröffentlichten Code enthält oder noch auf ein nicht zugehöriges Upstream-Repository verweist.
Untersuchen Sie nach Möglichkeit das veröffentlichte Paketarchiv (Tarball) und nicht nur das Quellcode-Repository, da Angreifer eine andere Version an npm senden können als die, die auf GitHub erscheint. Tools wie npm pack In Kombination mit einer manuellen Überprüfung (selbst wenn der Code transpiliert oder minimiert wurde) können offensichtliche Warnsignale wie seltsame Installationsskripte, verschleierte Blobs oder unerwartete Netzwerkaufrufe aufgedeckt werden.
Bei TypeScript-Bibliotheken, die lediglich Typdefinitionen und minimierten JavaScript-Code ausliefern, ist eine schnelle manuelle Prüfung schwieriger. Daher empfiehlt es sich, diese nur in einer strikten Sandbox zu verwenden oder sie, falls sie für den eigenen Stack kritisch werden, zu forken und aus dem Quellcode neu zu kompilieren. In manchen sicherheitskritischen Umgebungen entscheiden sich Teams nach gründlicher Prüfung tatsächlich dafür, Abhängigkeiten in private Registries auszulagern.
Machen Sie npm-Sicherheit zu einer Routine und nicht zu einer Notfallübung: Führen Sie aus npm audit Bereinigen Sie regelmäßig nicht benötigte Abhängigkeiten, halten Sie Ihre Sperrdateien aktiv und integrieren Sie SCA/SAST-Prüfungen in Ihre CI/CD-Pipeline. In Kombination mit sorgfältiger Kontoverwaltung und einem verantwortungsvollen Umgang mit Geheimnissen bieten diese Maßnahmen zwar keinen absoluten Schutz, reduzieren aber das Risiko, dass eine zufällige npm-Installation Ihre Systeme unbemerkt kompromittiert, drastisch.
