Supply-Chain-Security im Fokus Lehren aus dem npm-Supply-Chain-Angriff

Ein manipuliertes npm-Paket, viele betroffene Module und ein Angriff, der sich in den automatisierten Abläufen moderner Soft­ware­entwicklung versteckt hatte: Der Vorfall um „tinycolor“ zeigt, wie verwundbar Soft­ware­lieferketten heute sind. Warum klassische Schutzstrategien versagen und wie Unternehmen ihre Sicherheitsarchitektur jetzt anpassen müssen.

Im September 2025 schaffte es ein Vorfall im npm-Ökosystem in die Schlagzeilen: Über 40 Pakete, darunter auch das populäre Open-Source-Modul „tinycolor“, wurden kompromittiert und mit Schadcode versehen. Die Manipulation erfolgte über ein automatisiertes Skript, das Paketdateien herunterlud, manipulierte und erneut veröffentlichte. Die so eingeschleuste Schadfunktion suchte gezielt nach Zugangsdaten und Cloud-Credentials, die Entwickler versehentlich im Code hinterlegt hatten.

Was diesen Angriff so bemerkenswert macht, ist nicht nur sein technischer Ablauf, sondern auch seine Raffinesse: Er nutzte mit TruffleHog ein legitimes Open-Source-Tool, das üblicherweise zur Sicherheitsprüfung eingesetzt wird. Dadurch blieb die Aktivität lange unentdeckt – ein Beispiel aus dem Lehrbuch, das die neue Qualität von Lieferketten-Angriffen, die auf Vertrauen und Automatisierung in modernen Entwicklungsprozessen abzielen, verbildlicht.

Update: Neue Variante des Shai-Hulud Worm

Supply-Chain-Angriff trifft über 1.000 npm-Pakete

Anatomie eines Supply-Chain-Angriffs

Angriffe auf die Lieferkette zielen darauf ab, nicht direkt ein Unternehmen, sondern dessen Softwarelieferkette zu kompromittieren – also Werkzeuge, Bibliotheken oder Abhängigkeiten, auf die Entwickler täglich zugreifen. Statt den direkten Weg zu nehmen, infizieren Angreifer die Pfade, über die Software entsteht und verteilt wird.

Im Fall von npm wurde der Angriff automatisiert: ein manipuliertes Modul modifizierte nachgelagerte Projekte, injizierte Schadcode und veröffentlichte sie neu – alles im Hintergrund. Dass ein eigentlich legitimes Tool dabei als Vehikel diente, zeigt den Trend, dass Angreifer zunehmend auf „Living off trusted code“ setzen: Sie verstecken sich in eben jenen Mechanismen, die ursprünglich für Qualität und Effizienz sorgen sollen.

Gerade Open-Source-Ökosysteme sind dafür besonders anfällig. Vertrauen, Offenheit und schnelle Updates sind hier ein Teil der DNA – und genau diese Eigenschaften werden zunehmend ausgenutzt.

Strategien für eine sichere Software-Lieferkette

So funktionieren Supply-Chain-Attacks

Warum klassische Schutzmechanismen versagen

Die meisten Sicherheitsstrategien konzentrieren sich auf die Verteidigung von außen nach innen: Firewalls, Endpoint-Protection, Netzwerksegmentierung. Doch bei Supply-Chain-Angriffen kommt der Feind mit einem digital signierten, scheinbar vertrauenswürdigen Code direkt durch die Vordertür.

Ein Kernproblem liegt in der impliziten Vertrauenskette moderner Entwicklung. Sobald ein Paket oder Tool einmal als „sicher“ gilt, wird es automatisiert weiterverwendet, oft ohne manuelle Prüfung. Hinzu kommt der Trend zu KI-gestützten Entwicklungsumgebungen und sogenannten „vibe coding“-Tools wie Cursor oder Base44, die Codevorschläge oder Bibliotheken automatisch integrieren. Was Effizienz steigert, öffnet zugleich aber auch neue Angriffsflächen und verlagert das Risiko aus der Produktion in die Entwicklung.

Kurz gesagt: Die Geschwindigkeit, mit der Software heute entsteht, überholt oft die Fähigkeit, sie sicher zu gestalten.

Cyber-Risikomanagement in der Supply Chain

Eskalierende Bedrohungslandschaft für Lieferketten

Strukturelle und strategische Lehren

Der npm-Vorfall zeigt, dass die Sicherheit der Lieferkette nicht nur eine technische, sondern auch eine strukturelle Herausforderung ist. Unternehmen müssen ihre Sicherheitsarchitektur so organisieren, dass Vertrauen nicht automatisch entsteht, sondern aktiv verdient werden muss.

Ein zentrales Prinzip lautet dabei „Zero Trust for Code“. Genau so, wie der klassische Zero-Trust-Ansatz jede Identität und jedes Gerät überprüft, muss auch jeder Code – ganz egal, aus welcher Quelle – validiert und kontrolliert werden, bevor er produktiv eingesetzt werden kann.

Dies umfasst:

• Isolierte Testumgebungen, in denen neue oder aktualisierte Pakete geprüft werden, bevor sie in die Entwicklungs- oder Produktionsumgebung gelangen.

• Policy-basierte Freigaben, um sicherzustellen, dass nur geprüfte Module genutzt werden.

• Automatisierte Überwachung von Abhängigkeiten, die ungewöhnliche Änderungen oder neue Maintainer erkennt.

Ein weiterer kritischer Punkt ist der Umgang mit Zugangsdaten. Der npm-Angriff zielte proaktiv auf Tokens und Cloud-Schlüssel ab, also auf genau das, was Entwicklern oft „nebenbei“ in den Code rutscht. Secrets-Management muss daher zentralisiert, automatisiert und Teil der Sicherheitsstrategie sein. Die regelmäßige Rotation von Tokens, die Nutzung temporärer Credentials und der Einsatz von Vault-Lösungen sind keine besondere Kür, sondern schlichtweg Pflicht.

Neue Angriffstechniken der Cyberkriminellen

Neue Wege für eine erfolgreiche Malware-Infektion

Empfehlungen für Security-Teams

Um sich besser gegen Supply-Chain-Angriffe zu wappnen, sollten Unternehmen ihre Entwicklungs- und Sicherheitsprozesse besser verzahnen. Das bedeutet, Sicherheitsrichtlinien bereits im Code- und Build-Prozess zu verankern („Shift-Left“) – allerdings ohne die Entwickler mit manuellen Prüfungen zu überlasten.

Do´s:

• Tokens und Secrets regelmäßig rotieren und automatisiert verwalten.

• Neue Packages und Tools zunächst in abgeschlossenen Testumgebungen evaluieren.

• Verdächtige Änderungen an Codeabhängigkeiten aktiv überwachen.

• Zugriffskontrollen konsequent nach dem Least-Privilege-Prinzip umsetzen.

• Wenn möglich: Just-In-Time Zugriffe / Dynamic Secrets für Machine-Kommunikation etablieren

Dont´s:

• Tokens oder API-Schlüssel lokal speichern oder im Code hinterlegen.

• Tools oder Repositories blind vertrauen – auch nicht, wenn sie „offiziell“ oder weit verbreitet sind.

• Sicherheitsfreigaben umgehen, um Entwicklungszyklen zu verkürzen.

Langfristig führt für Unternehmen kein Weg daran vorbei, ihre gesamte Softwarelieferkette, von externen Bibliotheken bis hin zu internen Build-Systemen, als kritische Infrastruktur zu begreifen.

Dateilose Angriffe im Arbeitsspeicher

Warum Fileless Malware klassische Abwehrmechanismen aushebelt

Fazit: Vom Vorfall zur Resilienz

Der npm-Angriff war kein Einzelfall, sondern Teil einer merklichen Welle von Supply-Chain-Attacken, die 2025 das Open-Source-Ökosystem erschüttert haben. Die Moral aus der Geschichte: Wer Software entwickelt, ist Teil einer Lieferkette und damit auch Teil eines Risikosystems.

Unternehmen, die ihre Entwicklungsumgebungen strikt vor Produktivsystemen trennen, Code-Zugriffe konsequent absichern und ein Zero-Trust-Verständnis auf Code-Ebene etablieren, werden langfristig resilienter sein.

Denn Sicherheit in der Softwareentwicklung bedeutet heute vor allem eines: nicht mehr automatisch zu vertrauen, sondern systematisch zu überprüfen.

Über den Autor: Fabian Hotarek ist seit 2016 in verschiedenen Pre-Sales-Positionen in der DACH- und CEE-Region bei CyberArk tätig.

(ID:50704271)