Shai-Hulud, npm und moderne Software-Lieferketten

Im September 2025 widerfuhr dem npm-Ökosystem eine der bislang folgenschwersten Kompromittierungen der Software-Lieferkette. Ein sich selbst verbreitender Wurm, der heute allgemein als Shai-Hulud bezeichnet wird, kompromittierte Hunderte von npm-Paketen, sammelte Entwickler- und CI/CD-Anmeldedaten und nutzte diese Anmeldedaten, um sich im Ökosystem zu verbreiten, indem er unter der Identität legitimer Nutzer weitere bösartige Updates veröffentlichte. Innerhalb weniger Wochen folgte eine zweite Welle, oft als „Shai-Hulud 2.0” bezeichnet, die die ursprünglichen Techniken verfeinerte, frühere Engpässe beseitigte und den Umfang des Angriffs dramatisch vergrößerte, sodass letztendlich hunderte von Paketen und Zehntausende von GitHub-Repositorys betroffen waren.

Wie der Angriff ablief: Diebstahl von Anmeldedaten und wurmartige Verbreitung.

Die technischen Mechanismen des Angriffs sind mittlerweile gut dokumentiert. Der erste Zugriff erfolgte über Phishing oder gestohlene Tokens, woraufhin bösartiger Code in npm-Pakete eingeschleust wurde, häufig über Hooks wie Preinstall- oder Postinstall-Skripte. Nach der Ausführung durchsuchte die Malware die Rechner der Entwickler und CI-Umgebungen nach npm-Tokens, persönlichen GitHub-Zugriffstokens, SSH-Schlüssel  und Anmeldedaten von Cloud-Anbietern, und schleuste diese in von Angreifern kontrollierte GitHub-repositories. In vielen Fällen installierte oder modifizierte die Malware auch GitHub-Actions-Workflows, um Persistenz zu erreichen und weiterhin „secrets“ zu sammeln. Der neuartigste Aspekt war der wurmartige Verbreitungsmechanismus: Fand die Malware gültige npm-Anmeldedaten, veröffentlichte sie automatisch bösartige Versionen weiterer Pakete des kompromittierten Maintainers und verwandelte reguläre Paketveröffentlichungs-Workflows in einen Verstärkungsvektor.

Ausnutzung von Vertrauensannahmen in der modernen Softwareentwicklung

Was Shai-Hulud besonders bedeutsam macht, ist nicht nur sein Umfang, sondern auch die Tatsache, dass es nicht auf der Ausnutzung einer einzelnen Schwachstelle oder eines neuartigen Fehlers in npm selbst beruhte. Stattdessen nutzte es eine Reihe tief verwurzelter Annahmen aus, die der modernen Softwareentwicklung zugrunde liegen: Entwickler gehen davon aus, dass ein Paketname zu dem von ihnen erwarteten Code führt, dass veröffentlichte Pakete von ihren legitimen Entwicklern erstellt wurden, dass verteilte Artefakte dem überprüften Quellcode entsprechen und dass CI/CD-Systeme ausschließlich im Dienste des Projekts stehen, zu dem sie gehören. Diese Annahmen sind kein Zufall, sondern ermöglichen die großflächige Wiederverwendung von Open-Source-Software. Shai-Hulud hat jedoch gezeigt, wie leicht diese Annahmen als Waffe eingesetzt werden können, sobald Identität und Automatisierung kompromittiert sind.

Sofortmaßnahmen: Abhängigkeitsprüfung, SBOMs und ihre Grenzen

Unmittelbar nach dem Angriff betonten Hersteller und Behörden in ihren Leitlinien durchweg die Bedeutung von Abhängigkeitsprüfungen, Versionsfestlegung, Rotation von Anmeldedaten und der Verwendung von Lockfiles zur Identifizierung betroffener Komponenten. Diese Reaktion war in ordnung, aber es ist wichtig, genau zu wissen, was diese Maßnahmen leisten können und was nicht. Software Bills of Materials (SBOM) und Software Composition Analysis (SCA)-Tools sind äußerst effektiv, um Fragen zu beantworten, ob ein bestimmtes Paket oder eine bestimmte Version in einem System vorhanden war, wann es eingeführt wurde und wie weit es sich in den Umgebungen verbreitet hat. Mit anderen Worten: Sie sind für die Analyse von Vorfällen, Bewertung der Auswirkung und die Behebung unerlässlich. Ohne genaue Kenntnisse der Abhängigkeiten wären viele Unternehmen nicht in der Lage gewesen, festzustellen, ob sie überhaupt betroffen waren.

SBOMs als Infrastruktur für Transparenz, nicht als präventive Kontrolle

SBOMs und SCA erkennen zwar keinen böswilligen Code in neu veröffentlichten Paketen, spielen jedoch eine entscheidende Rolle, sobald böswillige Aktivitäten oder eine anfällige Komponente identifiziert werden. Sie verhindern weder den Diebstahl von Anmeldedaten in CI/CD-Umgebungen noch garantieren sie, dass ein veröffentlichtes Artefakt den überprüften Quellcode originalgetreu widerspiegelt. Wenn eine kompromittierte Paketversion in Schwachstellen- oder Bedrohungsdatenbanken verfolgt wird, ermöglichen SBOMs Unternehmen eine schnelle Ermittlung der Gefährdung über Produkte und Abhängigkeitsbäume hinweg und unterstützen so die Eindämmung, Behebung und Minimierung der Auswirkungen. Auf diese Weise sorgen SBOMs für Transparenz und sind der notwendige erste Schritt hin zu präventiven Sicherheitsmechanismen.

Automatisierung, KI und die Beschleunigung von Risiken in der Lieferkette

Der breitere Kontext, in dem Shai-Hulud entstand, ist geprägt von einer rasch zunehmenden Automatisierung in der Softwareentwicklung, einschließlich des wachsenden Einsatzes von KI-gestützter Codierung und Analyse. Die Automatisierung senkt die Kosten für die Veröffentlichung, Aktualisierung und Integration von Code, während KI-Tools die Hürden für die Erstellung großer Codemengen und schnelle Änderungen verringern. Diese Entwicklungen können die Produktivität erheblich verbessern, und es gibt konkrete Beispiele dafür, dass KI in Kombination mit genauer Überprüfung  zur Erstellung hochwertiger Analysen eingesetzt werden kann. Eine Sorge ist jedoch, dass große Sprachmodelle grundsätzlich nicht deterministische Systeme sind, die keine Garantien bieten, wie dies bei Compilern oder herkömmlichen Tools der Fall ist.

Wenn Automatisierung nicht nur die Produktivität, sondern auch Fehler skaliert

Diese Unterscheidung ist für die Sicherheit der Lieferkette von Bedeutung, da nicht deterministische Systeme Änderungen hervorrufen können, die plausibel erscheinen, dabei jedoch Annahmen, Invarianten oder Sicherheitseigenschaften verletzen, die im Code selbst nicht explizit enthalten sind. Die Integration solcher Ergebnisse ohne ausreichende Überprüfung in automatisierte Pipelines beschleunigt sowohl die Entwicklung als auch die Verbreitung von Fehlern. In Bezug auf die Lieferkette spiegelt dies die Dynamik wider, die in Shai-Hulud zu beobachten ist: Die Automatisierung verstärkt sowohl legitime Aktivitäten als auch Missbrauch, und kleine Fehler oder Kompromisse können zu systemischen Fehlern führen.

Warum prozessorientierte Regulierung wichtig ist: Lehren für das Gesetz zur Cyber-Resilienz

In diesem Zusammenhang sind Regulierungsinitiativen wie der EU Cyber Resilience Act zu verstehen. Der CRA verspricht weder eine Software ohne Schwachstellen, noch verbietet er die Verwendung von Open Source, Automatisierung oder KI. Stattdessen legt er den Schwerpunkt auf sichere Entwicklungsprozesse, die Rückverfolgbarkeit von Komponenten, den Umgang mit Schwachstellen und die Verantwortung nach der Markteinführung. Shai-Hulud liefert ein konkretes Beispiel dafür, warum dieser prozessorientierte Ansatz wichtig ist. Der Kernfehler lag nicht in einer bestimmten Schwachstelle, sondern in einem Verletzung des Vertrauens in Identitäten, der Handhabung von Anmeldedaten und automatisierten Verteilungsmechanismen, wodurch sich ein Sicherheitsvorfall schneller ausbreiten konnte, als die Organisationen seine Auswirkungen einschätzen konnten.

Einführung von „Friction“ zur Verbesserung der Widerstandsfähigkeit von Ökosystemen

Ein wiederkehrendes Thema in der Analyse nach einem Vorfall ist die Notwendigkeit, bewusste Bruchstellen in Software-Lieferketten einzuführen, wie z. B. ein „Mindestalter“ für ein Release, strengere Standardeinstellungen für die Authentifizierung, kurzlebige Anmeldedaten, Build-Bescheinigungen und strengere Kontrollen für CI/CD-Workflows. Diese Maßnahmen beseitigen zwar nicht das Risiko, verlangsamen jedoch dessen Ausbreitung und schaffen Raum für Erkennung, Überprüfung und Reaktion. In der Praxis hängt die Widerstandsfähigkeit oft weniger davon ab, jeden Ausfall zu verhindern, als vielmehr davon, sicherzustellen, dass Ausfälle nicht sofort eine Kettenreaktion im gesamten Ökosystem auslösen.

Von der Erkennung zur Verifizierung: Aufbau von evidenzbasiertem Vertrauen

Letztendlich kann keine einzelne Schutzmaßnahme ausgeklügelte Angriffe auf die Lieferkette verhindern. Aber Transparenz ist die Grundlage für alle anderen Maßnahmen. Schutzmaßnahmen müssen daher über die Erkennung hinausgehen und bis zur Verifizierung reichen. Vertrauenswürdige Veröffentlichungsworkflows, kurzlebige Anmeldedaten und digitale „Beglaubigungen“, wie sie in der Trusted Publishing Initiative von PyPI und crates.io entstanden sind. SBOMs und Abhängigkeits-Scans liefern eine erste Übersicht. Sie zeigen Ihnen, was sich einem Paket befindet, schon bevor Sie feststellen können, ob sie sicher ist. Sie ermöglichen proaktives Blockieren, fundiertes Patchen und schnelle Triage. Bei Bitsea integrieren wir ähnliche Konzepte in unser Open-Source-Toolkit OCCTET, das Unternehmen dabei hilft, Herkunft, Änderungen und Risiken über den gesamten Software-Lebenszyklus hinweg zu verfolgen.

Fazit: Vertrauen in die Software-Lieferkette explizit festlegen

Shai-Hulud ist ein Weckruf, Systeme zu entwickeln, bei denen Vertrauen nicht nur implizit vorhanden ist, sondern auf Fakten basiert. Dieser Weg beginnt mit der Beantwortung grundlegender Fragen wie: Was steckt in Ihrer Software? Woher kommt sie und wie wird sie gewartet?

Wenn Sie Hilfe benötigen um sicherzustellen, dass sie eine vertrauenswürdige Software-Lieferkette haben, unterstützt Bitsea Unternehmen dabei, diese Annahmen explizit und überprüfbar zu machen. Dazu gehören die Analyse von Abhängigkeitsbäumen und SBOMs, die Prüfung von Open-Source-Komponenten und Build-Artefakten sowie die Bewertung von Compliance-Verpflichtungen gemäß Regularien wie dem Cyber Resilience Act.