Von Dune zu npm: Der Shai-Hulud-Wurm definiert das Risiko in Supply Chain neu

Sep 17, 2025 von OPSWAT

Jetzt teilen

Fans von Dune werden "Shai-Hulud" als den Namen der kolossalen Sandwürmer kennen, die die Wüste mit ihrer unaufhaltsamen Kraft umgestalten. Jetzt sieht sich die Open-Source-Gemeinschaft mit einer ähnlich gewaltigen Cyber-Bedrohung konfrontiert. Am 15. September sah sich die Open-Source-Software-Gemeinschaft mit einer ihrer bisher schwersten Krisen konfrontiert: Ein sich selbst replizierender Wurm, bekannt als Shai-Hulud, bewegte sich durch das npm-Ökosystem und kompromittierte innerhalb von Stunden mehr als 180 Pakete.

Vertrauenswürdige Bibliotheken wie @ctrl/tinycolor, crowdstrike-nodejs, string-kit, json-sugar, photon-colors und Abzweigungen von typed.js und Datum und Uhrzeit sind bereits betroffen. Mit Millionen von Downloads pro Woche ziehen Unternehmen unwissentlich aktive Infektionen direkt in ihre Build-Pipelines ein.

Der Wurm nutzt npm-Lifecycle-Hooks aus, um GitHub- und Public-Cloud-Anmeldedaten zu stehlen, und verwendet diese Geheimnisse dann, um vergiftete Updates für andere Projekte zu veröffentlichen.

Angriffsfluss

Eine kompromittierte Version von @ctrl/tinycolor injiziert ein lokales bösartiges Skript (bundle.js).
Das Skript bundle.js lädt TruffleHog herunter und führt es aus, um auf dem Rechner des Opfers nach GitHub-Geheimnissen zu suchen.
Anhand der ermittelten GitHub-Geheimnisse zählt das Skript die zugänglichen Repositorys auf (Eigentümer, Mitarbeiter oder Organisationsmitglied).
Für jedes Repository holt es den Standardzweig, erstellt eine shai-hulud Zweig, und lädt eine Workflow-Datei auf .github/workflows/shai-hulud-workflow.yml .
Der Workflow ist so konfiguriert, dass er bei Push-Ereignissen ausgelöst wird. Der GitHub Actions-Runner führt den Auftrag im Repository-Kontext aus, der Zugriff auf Geheimnisse hat.
Der Arbeitsablauf liest GitHub-Geheimnisse aus und exfiltriert sie an einen vom Angreifer kontrollierten Endpunkt.

Warum dies jetzt und auf lange Sicht wichtig ist

Open Source ist von Haus aus offen. Über die npm-Registry werden jeden Monat Hunderte von Milliarden Downloads abgewickelt, und jeder kann ein Paket veröffentlichen. Diese Offenheit treibt Innovationen voran, schafft aber auch Möglichkeiten für Angreifer, Vertrauen in großem Umfang zu missbrauchen.

Der Ausbruch macht eine Tatsache unausweichlich: Vertrauen ist nicht von Dauer. Ein Paket, das heute noch sicher ist, kann morgen schon gefährdet sein.

Empfehlung: Genaue Angabe der Abhängigkeitsversionen

Wir empfehlen Entwicklern dringend, die automatische Installation der neuesten Version zu vermeiden. Legen Sie stattdessen eine bestimmte Version fest, die installiert werden soll, und überprüfen Sie sie manuell und aktualisieren Sie nur nach Überprüfung auf neuere Versionen.

Abhängigkeiten, die mit >= oder * deklariert sind, können unbeabsichtigte Aktualisierungen, einschließlich kompromittierter Versionen, mit sich bringen. Geben Sie eine genaue, überprüfte Version an:

"dependencies": {
  "lodash": "4.17.0"
}

Führen Sie Upgrades nur durch, nachdem Sie neue Versionen auf Authentizität und Sicherheit überprüft haben.

Jetzt vs. Nächstes: Ausgleich zwischen Automatisierung und menschlichem Eingreifen

Jetzt: Sofortige Reaktion	Nächste: Langfristige Resilienz
Automatisiert: Prüfen Sie npm-Abhängigkeiten und scannen Sie Artefakte mit mehreren Engines. Menschlich: Entwickler unterbrechen Blindinstallationen und bestätigen Abhängigkeitsquellen manuell.	Automatisiert: Integrieren Sie eine kontinuierliche SBOM-Validierung und Malware-Scans in jede Pipeline. Menschlich: Die Sicherheitsteams überprüfen regelmäßig Pakete mit hohem Risiko und eskalieren, wenn Anomalien auftreten.
Automatisiert: Aufhebung und Rotation offener Geheimnisse. Menschlich: Sicherheitsteams bewerten die Verwendung verdächtiger Zugangsdaten und entscheiden über Maßnahmen zur Eindämmung.	Automatisiert: Durchsetzung automatischer Rotationsrichtlinien und Voreinstellungen mit geringsten Rechten. Menschlich: Führungskräfte legen Governance-Standards fest und sorgen dafür, dass das Vertrauen in die Lieferkette gewahrt bleibt.
Automatisiert: Durchsetzung von MFA und Signaturprüfungen in CI/CD. Menschlich: Die Führungskräfte entscheiden, wann sie die Lieferung verlangsamen, um die Integrität zu schützen.	Automatisiert: Verlangen Sie signierte Commits und eine überprüfbare Build-Provenance für alle Releases. Menschlich: Vorstände behandeln Software-Vertrauen als eine strategische Frage der Widerstandsfähigkeit, nicht als ein Kontrollkästchen für die Einhaltung von Vorschriften.

Das größere Bild

Für Führungskräfte ist dieser Angriff eine Erinnerung daran, dass das Risiko in der Software-Lieferkette ein Unternehmensrisiko ist. Die Aufsichtsbehörden erwarten überprüfbare Kontrollen, und die Kunden erwarten einen Nachweis der Integrität. Vorstände können die Verantwortung für den Code, der kritische Abläufe steuert, nicht länger aufschieben.

Für Praktiker zeigt der Ausbruch, dass Pipelines weiterentwickelt werden müssen. Jede Open-Source-Abhängigkeit sollte als nicht vertrauenswürdig behandelt werden, bis sie sich als sicher erwiesen hat. SBOMs, Malware-Scans und Bereinigung bilden die Grundlage, aber menschliches Bewusstsein - Innehalten, Hinterfragen, Eskalieren - ist das, was verhindert, dass blinde Automatisierung den nächsten Wurm importiert.

Die Sichtweise der OPSWAT

Aufbau von Vertrauen in Supply Chain

Vorfälle wie Supply-Chain-Angriffe auf Open-Source-Umgebungen wie npm sind der Beweis dafür, dass Software-Lieferketten heute kritische Arbeitslasten darstellen. Die Branche muss von blindem Vertrauen zu überprüfbarem Vertrauen übergehen.
George Prichici
Vizepräsident für Produkte, OPSWAT

Wir bei OPSWAT glauben, dass Vertrauen in der Lieferkette aufgebaut und nicht vorausgesetzt werden muss. Unser Ansatz konzentriert sich auf Verteidigung in der Tiefe:

Umfassende Transparenz der Software-Lieferkette mit SBOM-Integration, um jede Softwarekomponente zu verfolgen, Schwachstellen zu erkennen, Risiken während des gesamten SDLC zu verwalten und die Herkunft in jeder Phase zu überprüfen.

Multiscanning mit 30+ Engines, um polymorphe Malware und andere Malware in Paketen abzufangen, insbesondere in Open-Source-Paketen Dritter.

CDR (Content Disarm and Reconstruction), um bösartige Nutzdaten zu neutralisieren, bevor sie ausgeführt werden.

Secure Speicher- und Übertragungskontrollen, die Vertrauensgrenzen über CI/CD-Pipelines hinweg durchsetzen.

Diese Kontrollen erkennen nicht nur Risiken, sondern bereinigen auch aktiv Dateien und setzen Vertrauen durch, wodurch die Wahrscheinlichkeit verringert wird, dass sich Vorfälle wie dieser weiter ausbreiten.

Schnelle Entwicklung und hohe Sicherheit schließen sich nicht gegenseitig aus. Entwicklerteams benötigen automatisierte Scan- und Freigabe-Workflows, die in die Software-Lieferkette integriert sind, damit sie den Code schützen können, ohne das Tempo zu verlangsamen.
George Prichici
Vizepräsident für Produkte, OPSWAT

Sicherheit, die mit der Entwicklung schritthält

Mit OPSWAT lässt sich die Sicherheit direkt in bestehende Arbeitsabläufe integrieren:

CI/CD-Pipeline-Integration - Automatisierte Scans und Durchsetzung von Richtlinien in Jenkins, GitHub Actions, GitLab und anderen Build-Umgebungen.

Nahtloses Scannen von Artefakten - Validieren Sie npm-Pakete, Container und Binärdateien als Teil von Routine-Build-Schritten.

SBOM-Generierung und -Validierung bei Bedarf - Erstellen und verifizieren Sie SBOMs automatisch für jedes Release und stellen Sie die Provenienz ohne zusätzlichen Aufwand sicher.

Transparentes Entwicklererlebnis - Sicherheit läuft im Hintergrund und zeigt Probleme nur dann an, wenn ein Eingreifen wirklich erforderlich ist.

Automatisierte Abhilfemaßnahmen - Quarantäne oder Bereinigung kompromittierter Dateien ohne Unterbrechung der Builds.

Eine auf Geschwindigkeit ausgerichtete Entwicklungskultur muss nicht mit der notwendigen Sicherheitsvalidierung kollidieren; automatisierte Scan- und Genehmigungsworkflows sollten ein Muss sein, mit minimalen Auswirkungen auf die Entwicklungsgeschwindigkeit.

Durch die Einbettung dieser Fähigkeiten in den Software-Lebenszyklus hilft OPSWAT Unternehmen, sowohl Entwicklungsgeschwindigkeit als auch verifizierbares Vertrauen zu erreichen - ein Gleichgewicht, das, wie der npm-Vorfall beweist, heute unerlässlich ist.

Mehr erfahren

Das Mitnehmen

Der npm-Wurm Shai-Hulud ist ein deutliches Zeichen für die Bedrohungen, denen Software heute ausgesetzt ist. Angreifer müssen nicht in Ihre Codebasis eindringen. Sie können Sie dazu überreden, sie zu installieren. Überprüfen Sie jedes Artefakt, integrieren Sie Widerstandsfähigkeit in jede Phase und befähigen Sie Menschen zum Handeln, wenn Automatisierung allein nicht ausreicht. Unternehmen, die dies jetzt ernst nehmen, werden die Zukunft der sicheren Software-Lieferketten bestimmen.

Sind Sie bereit, Ihre Software-Lieferkette mit maßgeschneiderten, nahtlos integrierten Lösungen vor den neuesten Cyber-Bedrohungen zu schützen?

Sprechen Sie mit einem Experten