In vielen Unternehmen herrscht noch immer die Annahme, dass Cyberangriffe primär auf Firewalls, Server oder Mitarbeiter abzielen. Die Realität sieht inzwischen anders aus. Angreifer attackieren zunehmend die digitale Supply-Chain, also genau die Softwarebausteine, Cloud-Dienste und Entwicklungsprozesse, auf denen moderne Unternehmen täglich aufbauen.
Der aktuelle „Mini Shai Hulud“-Vorfall rund um kompromittierte npm-Pakete zeigt das sehr deutlich. Was zunächst wie ein technisches Open-Source-Problem wirkt, betrifft in Wahrheit nahezu jede Branche. Denn npm-Pakete stecken heute in Webportalen, Kundenplattformen, Dashboards, internen Anwendungen, mobilen Apps und Cloud-Services. Oft werden sie automatisiert eingebunden, aktualisiert und produktiv genutzt, ohne dass Unternehmen jede einzelne Abhängigkeit aktiv prüfen können.
Genau deshalb wird Software-Supply-Chain-Security zunehmend zum Management-Thema. Und genau deshalb spielt NIS2 dabei eine zentrale Rolle. Die Richtlinie fordert nicht nur klassische IT-Sicherheitsmaßnahmen. Sie verpflichtet Unternehmen ausdrücklich dazu, Risiken in der Lieferkette zu bewerten, geeignete Schutzmaßnahmen umzusetzen und Sicherheitsvorfälle nachvollziehbar zu managen. Damit wird aus einem Entwicklerproblem plötzlich eine Governance- und Haftungsfrage.
Althergebrachte Sicherheitsansätze halten nicht mehr Stand
Denn Mini-Shai-Hulud zielt nämlich nicht primär auf den Endnutzer. Der Angriff zielt auf die Maschinen und alle Prozesse, mit denen Software entsteht: Auf Developer-Workstations, CI/CD-Pipelines, Github-Tokens, npm-Publishing-Rechte oder Cloud-Credentials. Das ist strategisch relevant, denn wenn die Lieferkette kompromittiert wird, muss man nicht jede Zielorganisation einzeln angreifen. Das kompromittiert das Vertrauen, auf dem moderne Softwareentwicklung basiert.
Besonders kritisch ist die Art der betroffenen Pakete. Es geht nicht nur um exotische Abhängigkeiten am Rand. Betroffen waren Pakete aus weit verbreiteten Ökosystemen wie „TanStack“, „AntV“, „echarts-for-react“ oder „timeago.js“. Solche Komponenten finden sich typischerweise in Web-Anwendungen, internen Portalen, Dashboards, Datenvisualisierungen, Management-Oberflächen und Entwicklerwerkzeugen. Also genau dort, wo Unternehmen heute digitale Prozesse abbilden.
Supply-Chain-Security wird zu einem Lagebildproblem
Eine SBOM (Software Bill of Materials) kann zeigen, welche Komponenten theoretisch im Einsatz sind. Ein Vulnerability-Scanner kann bekannte CVEs finden. Ein SCA-Tool kann Abhängigkeiten prüfen. Aber keines dieser Werkzeuge beantwortet allein die entscheidenden Fragen: Welche Kampagne läuft gerade und welche Pakete sind betroffen? Welche Infrastruktur nutzt der Angreifer? Welche internen Anwendungen hängen an diesen Paketen? Und welche Maßnahmen haben Priorität, weil sie tatsächliche Angriffswege unterbrechen?
Genau hier gehört Cyber-Threat-Intelligence in die Supply-Chain-Diskussion. CTI darf nicht nur als Feed mit Indicators of Compromise verstanden werden. Richtig eingesetzt verbindet CTI externe Angreiferinformationen mit interner technischer Realität. Also mit Paketlisten, Repositories, Build-Pipelines, Cloud-Umgebungen, Secrets-Management und Business-Kritikalität.
Das ist der Unterschied zwischen Alarm und Entscheidung. Ohne CTI werden meist nur npm-Pakete geprüft. Moderne CTI hingegen liefert folgende Antworten: „Die Kampagne stiehlt CI/CD-Secrets über kompromittierte Pakete und die betroffenen Repositories nutzen diese Abhängigkeiten. Diese Pipelines haben Zugriff auf produktionsnahe Cloud-Umgebungen. Credentials müssen zuerst rotiert werden und die Builds gestoppt werden. Die Lieferanten werden kontaktiert und das Risiko muss ans Management gemeldet werden.“
Die untenstehende Abbildung zeigt, wie das in der Praxis aussieht. Dort lässt sich die Mini-Shai-Hulud-Kampagne nicht nur als einzelner Alarm betrachten, sondern als strukturiertes Lagebild: Zwei Angriffswellen, die erste am 11. Mai gegen TanStack-Pakete und ein weit verbreitetes Jenkins-Plugin, die zweite am 19. Mai gegen Datenvisualisierungsbibliotheken und Entwicklerwerkzeuge. Dazu die eingesetzten Schadkomponenten, die betroffenen Ökosysteme, die Quelle der Analyse und eine Einschätzung der Zuverlässigkeit. All das nicht als loser Datenpunkt, sondern eingebettet in einen Zusammenhang und verknüpft mit bekannten Angriffsmustern, betroffenen Branchen und konkreten Handlungsoptionen. Genau diese Verknüpfung macht den Unterschied zwischen einer Warnung, die im Posteingang untergeht, und einer Entscheidungsgrundlage, mit der ein Sicherheitsteam innerhalb von Minuten priorisieren kann, welche Repositories, Pipelines und Zugangsdaten zuerst geprüft werden müssen (siehe Abbildung).
NIS2 fordert all diese Fähigkeiten zur Erkennung nun ein. Die Richtlinie verlangt aber nicht nur technische Maßnahmen. Sie verlangt ein angemessenes Risikomanagement für Netz- und Informationssysteme. Dazu gehören Supply Chain Security, sichere Entwicklung, Vulnerability-Handling, Incident-Handling, Access-Control und die Bewertung von Lieferantenrisiken. Damit reicht es nicht mehr, nach einem Vorfall zu sagen: „Unsere Entwickler haben reagiert.“ Unternehmen müssen zeigen können, dass sie Risiken in ihrer digitalen Lieferkette erkennen, bewerten, priorisieren und steuern.
Was aus Mini-Shai-Hulud folgen muss
Doch dass Risikoerkennung innerhalb der Lieferkette nicht so leicht zu bewerkstelligen ist, zeigt sich nun am Beispiel Mini Shai Hulud. Der Angriff bewegt sich schneller als klassische Governance-Prozesse. Er nutzt legitime Publishing-Mechanismen, missbraucht vertrauenswürdige Build-Workflows und erzeugt eine Kettenreaktion, bei der ein kompromittierter Zugang zum nächsten kompromittierten Paket führen kann.
Das ist kein Randproblem der Softwareentwicklung. Es ist ein operatives Cyberrisiko mit möglichem Business Impact. Die Konsequenz ist klar: Supply-Chain-Security braucht drei Ebenen: Erstens Transparenz über Abhängigkeiten, Pakete, Build-Pipelines und Secrets. Zweitens technische Kontrollen wie isolierte Builds, restriktive Tokens, gehärtete CI/CD-Workflows, Secret Scanning, Dependency-Pinning und schnelle Credential-Rotation. Drittens Threat-Intelligence, die externe Kampagneninformationen in konkrete interne Prioritäten übersetzt.
Gerade die dritte Ebene fehlt in vielen Organisationen. CTI wird noch zu oft als Analystendisziplin verstanden oder als ein Thema für Spezialisten im SOC oder Threat-Intel-Team. Der Mini-Shai-Hulud-Fall zeigt das Gegenteil. CTI ist ein Steuerungsinstrument für Resilienz. Es hilft Unternehmen zu entscheiden, welche Supply-Chain-Risiken jetzt zählen und welche Maßnahmen zuerst Wirkung haben.
Fazit
NIS2 macht die genannten Fähigkeiten nicht weiter optional. Sie sind nun Teil der gesetzlich geforderten Nachweisfähigkeit. Die eigentliche Lehre aus Mini-Shai-Hulud ist deshalb nicht: „npm ist gefährlich.“ Die Lehre lautet: Wer seine Software-Lieferkette nicht threat-informed steuert, sieht den Angriff erst, wenn er bereits Teil der Verteilungskette geworden ist. Doch dann ist reine Prävention längst nicht mehr ausreichend.
Von Oliver Keizers, VP Sales Central EMEA, Filigran
