Software Supply Chain Attack

Software Supply Chain Attack bezeichnet einen Angriff, bei dem nicht deine Anwendung selbst, sondern ein Glied ihrer Lieferkette kompromittiert wird: eine Abhängigkeit aus npm oder Packagist, ein Build-Server, eine Paketregistry, ein Update-Kanal oder eine Erweiterung wie ein Shop-Plugin. Der Angreifer schleust Code dort ein, wo du ihm ohnehin vertraust, und dein eigener Installations- oder Deploy-Prozess verteilt ihn weiter. Das Opfer ist am Ende nicht der Maintainer, sondern jeder, der sein Paket installiert.

Der Begriff hat in den letzten drei Jahren eine Karriere gemacht, die er nicht verdient hätte. Was 2020 mit SolarWinds als Ausnahmefall für Nachrichtendienste galt, ist seit 2025 Alltag in jedem Node.js-Projekt: Ein Wurm kompromittiert ein Paket, das Paket stiehlt Tokens, die Tokens infizieren weitere Pakete. Niemand hat dich angegriffen, und trotzdem lagen deine AWS-Schlüssel in einem fremden GitHub-Repository.

Das Unangenehme an dieser Angriffsklasse: Sie entsteht nicht durch einen Fehler in deinem Code. Dein Team kann sauber programmieren, Reviews machen und jede Eingabe validieren, und trotzdem landet über npm install ein Credential-Stealer in der CI-Pipeline. Deshalb hat OWASP das Thema in der Ausgabe 2025 der OWASP Top 10 grundlegend neu geschnitten.

Einordnung: A03:2025 Software Supply Chain Failures

In den OWASP Top 10:2025 heißt die Kategorie A03:2025 Software Supply Chain Failures. Sie ersetzt die alte Kategorie „Vulnerable and Outdated Components“ aus 2021 und erweitert sie deutlich: Es geht nicht mehr nur um bekannte Schwachstellen in veralteten Bibliotheken, sondern um jede Kompromittierung beim Bauen, Verteilen oder Aktualisieren von Software.

Die Zahlen aus dem OWASP-Dokument sind bemerkenswert. In der Community-Umfrage setzten exakt 50 Prozent der Befragten diese Kategorie auf Platz 1, mehr als jede andere. Die Kategorie bündelt 6 CWEs, hat mit 5,72 Prozent die höchste durchschnittliche Incidence Rate aller zehn Kategorien und einen gewichteten Exploit-Score von 8,17. OWASP nennt als Beispiele ausdrücklich SolarWinds, Log4Shell und den Shai-Hulud-Wurm mit über 500 betroffenen Paketversionen.

Dass eine Kategorie mit nur 11 zugeordneten CVEs so weit oben steht, sagt etwas über die Datenlage: Supply-Chain-Vorfälle erzeugen selten eine CVE für das Opfer. Sie tauchen als Incident auf, nicht als Schwachstelle. OWASP selbst räumt ein, dass diese Fälle schwer zu erkennen sind, obwohl sie häufig vorkommen. Wer nur CVE-Scanner laufen lässt, sieht genau diesen Teil der Bedrohung nicht.

Angriffsformen: Wo die Lieferkette reißt

Eine Software-Lieferkette hat viele Glieder, und jedes davon ist ein eigener Angriffsvektor. Die Spannbreite reicht vom gestohlenen Maintainer-Passwort bis zum manipulierten Compiler. In der Praxis dominieren seit 2025 Angriffe auf Paketregistries, weil dort der Aufwand am geringsten und die Reichweite am größten ist. Die folgende Tabelle ordnet die wichtigsten Formen nach dem Glied, das sie treffen.

Manipulierte Builds: SolarWinds und xz-utils

Die zwei Lehrbuchfälle für manipulierte Builds liegen vier Jahre auseinander und könnten unterschiedlicher kaum sein. Bei SolarWinds wurde der Build-Prozess der Orion-Plattform so verändert, dass ein Backdoor in die signierten Updates der Versionen 2019.4 HF 5 bis 2020.2.1 HF 1 gelangte. Die amerikanische CISA warnte am 13. Dezember 2020 vor aktiver Ausnutzung (CISA Alert). OWASP beziffert die Zahl der betroffenen Organisationen auf rund 18.000.

Der Fall xz-utils vom März 2024 war ein Angriff auf ein Open-Source-Projekt von innen. Ein Mitwirkender erarbeitete sich über zwei Jahre Maintainer-Vertrauen und versteckte dann in den Release-Tarballs der Versionen 5.6.0 und 5.6.1 einen Mechanismus, der beim Bauen eine vorgefertigte Objektdatei in liblzma einschleuste. Ziel war der SSH-Daemon vieler Linux-Distributionen. CVE-2024-3094 bekam den CVSS-Höchstwert 10,0 (NVD). Entdeckt wurde er durch Zufall, weil ein Entwickler sich über 500 Millisekunden Login-Verzögerung wunderte.

Realbeispiele 2025 und 2026: Das npm-Jahr

Für Teams mit Node.js, NestJS oder einer Headless-Storefront ist die relevante Geschichte die der npm-Registry. Innerhalb eines Jahres hat sich dort ein Muster etabliert, das inzwischen einen Namen hat: der selbstverbreitende Registry-Wurm.

Shai-Hulud, erste und zweite Welle

Im September 2025 kompromittierte der Shai-Hulud-Wurm in mehreren Wellen Hunderte npm-Pakete. Das Prinzip: Ein Install-Skript stiehlt npm- und GitHub-Tokens des Entwicklers, der das Paket installiert, und nutzt diese Tokens, um alle Pakete, auf die der Entwickler Publish-Rechte hat, ebenfalls zu infizieren. Jedes Opfer wird damit zum Verteiler.

Shai-Hulud 2.0 folgte zwischen dem 24. November und dem 1. Dezember 2025. Microsoft veröffentlichte am 9. Dezember 2025 eine Handreichung zur Erkennung und Abwehr (Microsoft Security Blog). Die zweite Welle nutzte ein preinstall-Skript namens set_bun.js, installierte die Bun-Runtime, richtete auf den Opfer-Maschinen einen GitHub-Actions-Runner namens „SHA1HULUD“ ein und suchte mit TruffleHog nach Zugangsdaten. Betroffen waren Maintainer-Accounts von Zapier, PostHog und Postman.

Laut Microsoft kam im Mai 2026 eine kleinere Welle hinzu, die erstmals gleichzeitig npm und PyPI traf: über 170 npm-Pakete und 2 PyPI-Pakete in 404 bösartigen Versionen.

CHAINDROP, 4. August 2026

Am 4. August 2026 meldete Elastic Security Labs die Variante CHAINDROP: über 400 kompromittierte npm-Pakete mit zusammen mehr als 1,3 Milliarden Downloads im Monat (Elastic Security Labs). Darunter keyv mit 600 Millionen monatlichen Downloads, flat-cache mit 580 Millionen und cache-manager mit 16 Millionen. Der Payload trug die Beschreibung „Shai-Hulud: Here We Go Again“ und einen Credential-Harvester, der über 300 Muster absucht: Schlüssel für Anthropic, OpenAI und Gemini, Zugangsdaten für AWS, GCP und Azure, GitHub-Tokens, SSH-Keys und Kubernetes-Credentials.

Die Pointe für NestJS-Teams: keyv steckt in cache-manager, und cache-manager steht hinter dem CacheModule, das viele Projekte in der app.module.ts registrieren. Ob du betroffen warst, zeigt ein npm ls keyv im Projektordner. Wer das im August nicht wusste, hat mit hoher Wahrscheinlichkeit nicht nachgesehen.

npm 12 schaltet Install-Skripte ab

Die Registry hat reagiert, und zwar vor CHAINDROP. npm 12 erschien am 8. Juli 2026 und führt Install-Skripte von Abhängigkeiten standardmäßig nicht mehr aus; allowScripts ist jetzt eine explizite Freigabe pro Paket. Git-Abhängigkeiten (--allow-git) und entfernte Tarballs (--allow-remote) sind per Default gesperrt, und Zugriffstokens, die die Zwei-Faktor-Authentifizierung umgehen, sind abgekündigt (InfoQ, August 2026).

Laut JFrog steckten diese drei Vektoren in rund 53 Prozent der im Vorjahr beobachteten bösartigen npm-Angriffe. npm war damit der letzte große Paketmanager, der diese Defaults einführte; pnpm, yarn und bun hatten sie bereits.

Dass CHAINDROP vier Wochen nach npm 12 trotzdem über preinstall funktionierte, zeigt die Trägheit der Lieferkette: Ein neuer Default schützt nur Maschinen, auf denen er angekommen ist. CI-Images, Docker-Basisimages und Entwickler-Laptops mit npm 10 oder 11 waren weiterhin offen.

Die Größenordnung

Sonatype zählte im Jahr 2025 insgesamt 454.648 neu entdeckte bösartige Open-Source-Pakete, veröffentlicht im State of the Software Supply Chain Report vom 28. Januar 2026 (Infosecurity Magazine). 56 Prozent davon klassifiziert Sonatype als Repository-Missbrauch, 28 Prozent als potenziell unerwünschte Anwendungen. Der Befund im Report: Die Angriffe haben sich von Spam und Experimenten zu industrialisierten Kampagnen entwickelt.

Die Shopware-Seite: Apps und Plugins sind Code mit Shop-Rechten

Composer kennt keine Install-Skripte in der npm-Form, und Shopware-Plugins kommen überwiegend mit Review aus dem Shopware Store. Das heißt nicht, dass die Lieferkette eines Shops sicher ist. Sie verläuft nur woanders: durch die Erweiterungen selbst. Jede App, jedes Plugin ist fremder Code, dem du die Rechte deines Shops gibst, und zwar Kundendaten, Bestellungen, Zahlungsflüsse eingeschlossen.

Shopware hat Apps genau deshalb in eine Sandbox gesetzt: App Scripts laufen in einer eingeschränkten Twig-Umgebung, ohne direkten PHP-Zugriff. Am 25. August 2026 veröffentlichte Shopware jedoch das Advisory GHSA-6qhw-38wm-7g7h: Eine bösartige oder kompromittierte App konnte aus ihren App Scripts heraus beliebige PHP-Funktionen und Betriebssystembefehle mit den Rechten des Webserver-Prozesses ausführen, CVSS 9,6. Betroffen waren Shopware 6.5.4.0 bis 6.6.10.22 und 6.7.0.0 bis 6.7.13.0, gepatcht in 6.6.10.23 und 6.7.13.1.

Bereits am 11. März 2026 schloss Shopware mit CVE-2026-31889 (CVSS 8,9) eine Lücke in der App-Registrierung: Wer das App-Secret kannte, konnte über eine erneute Registrierung den Kommunikationskanal zwischen Shop und App auf einen eigenen Server umlenken und so die API-Zugangsdaten des Shops abgreifen (GitHub Advisory). Beide Fälle haben denselben Kern: Die Erweiterung ist Teil der Lieferkette, und ihre Vertrauensgrenze ist der Shop.

Für Shop-Betreiber folgt daraus eine simple Regel: Jede installierte Erweiterung ist ein Lieferant, der eine Sicherheitsbewertung verdient. Wer sie pflegt, wie schnell Updates kommen, welche Rechte sie anfordert und ob sie wirklich noch gebraucht wird. Ein Plugin, das seit zwei Jahren niemand mehr aktualisiert, ist kein Feature, sondern ein offener Posten.

Gegenmaßnahmen: Was wirklich schützt

Gegen Supply-Chain-Angriffe gibt es kein einzelnes Werkzeug, aber eine Handvoll Maßnahmen, die den Großteil der realen Vorfälle der letzten zwei Jahre abgefangen hätten. Die wichtigste ist unspektakulär: Lass dich nicht automatisch auf die neueste Version heben. Ein committetes Lockfile plus npm ci in der CI stellt sicher, dass genau die Versionen installiert werden, die jemand bewusst geprüft hat.

Eine Karenzzeit von einigen Tagen vor dem Übernehmen neuer Versionen hätte fast jede Shai-Hulud-Welle verpuffen lassen, weil die Registry die bösartigen Versionen innerhalb von Stunden bis Tagen entfernte.

Die zweite Maßnahme ist das Abschalten von Install-Skripten, solange du nicht auf npm 12 bist. In der CI sieht das so aus:

# Lockfile strikt, keine Install-Skripte von Abhängigkeiten
npm ci --ignore-scripts

# Prüfen, ob ein betroffenes Paket im Baum hängt
npm ls keyv

Pakete, die ohne Install-Skript nicht funktionieren (etwa native Addons), gibst du dann einzeln frei, statt allen Paketen pauschal Codeausführung zu erlauben. Genau dieses Opt-in-Modell ist seit npm 12 der Default.

Drittens brauchst du Sichtbarkeit: Eine Software Bill of Materials (SBOM) listet jede direkte und transitive Abhängigkeit mit Version. Bei der nächsten Welle beantwortet sie die Frage „sind wir betroffen?“ in Minuten statt in Tagen. OWASP nennt die SBOM als erste Präventionsmaßnahme der Kategorie A03.

Ergänzt wird sie durch Signaturen und Provenance: npm unterstützt Provenance-Attestierungen über Sigstore, mit denen sich nachweisen lässt, dass ein Paket aus einem bestimmten Repository und Build-Workflow stammt. Ein Paket ohne Provenance ist kein Ausschlusskriterium, aber ein Fragezeichen.

Viertens die Accounts: Zwei-Faktor-Authentifizierung auf allen npm-, Packagist- und GitHub-Konten, und zwar ohne langlebige Tokens, die den zweiten Faktor umgehen. Shai-Hulud lebte von genau solchen Tokens. CI-Pipelines sollten mit kurzlebigen, scope-begrenzten Credentials publizieren, idealerweise über OIDC statt gespeicherter Secrets. Das Least-Privilege-Prinzip gilt für Build-Jobs genauso wie für Nutzer.

Fünftens die Build-Umgebung selbst: Build-Server, Artefakt-Registries und Code-Repositories sind Produktionssysteme und gehören gehärtet, überwacht und mit getrennten Zuständigkeiten betrieben. OWASP empfiehlt ausdrücklich Separation of Duties in CI/CD und gestaffelte Rollouts statt gleichzeitiger Updates auf allen Systemen. Wer seine CI auf einem vergessenen Jenkins mit Admin-Token betreibt, hat eine Lieferkette mit offener Hintertür. Wenn du für dein Team eine Architektur willst, bei der diese Fragen von Anfang an mitgedacht sind, ist das Teil unserer Enterprise-Software-Entwicklung.

Regulatorik: NIS-2 und Cyber Resilience Act

Die Sicherheit der Lieferkette ist seit 2024 auch eine rechtliche Anforderung. Die NIS-2-Richtlinie verlangt von wichtigen und besonders wichtigen Einrichtungen ausdrücklich Maßnahmen zur „Sicherheit der Lieferkette“, einschließlich der Beziehungen zu direkten Anbietern und Dienstleistern. Wer unter NIS-2 fällt, muss belegen können, wie er die Sicherheit seiner Software-Zulieferer bewertet.

Der Cyber Resilience Act (CRA) geht einen Schritt weiter und adressiert die Hersteller von Produkten mit digitalen Elementen direkt. Die Verordnung trat am 10. Dezember 2024 in Kraft; die Meldepflichten für aktiv ausgenutzte Schwachstellen nach Artikel 14 gelten seit dem 11. September 2026, die vollständige Anwendung aller Pflichten folgt am 11. Dezember 2027 (CRA Artikel 69).

Ab dann sind unter anderem eine SBOM, ein Prozess für den Umgang mit Schwachstellen und sichere Update-Mechanismen Pflicht für alle Produkte, die in der EU in Verkehr gebracht werden. Für Software-Anbieter, Plugin-Hersteller und Agenturen, die eigene Produkte ausliefern, ist das die Frist, auf die sich die Gegenmaßnahmen oben beziehen.

Abgrenzung

Vulnerable and Outdated Components war bis 2021 die OWASP-Kategorie A06 und ist seit 2025 ein Teilaspekt von A03. Der Unterschied: Eine veraltete Komponente hat eine bekannte, zufällig entstandene Schwachstelle, die ein Scanner findet. Ein Supply Chain Attack bringt absichtlich eingeschleusten Schadcode in eine aktuelle Version, die kein CVE-Scanner kennt, bis die Registry reagiert hat.

Die Gegenmaßnahmen überschneiden sich, aber Patchen allein hilft gegen den zweiten Fall nicht; im Gegenteil, wer am Tag der Veröffentlichung auf die neueste Version aktualisiert, ist beim Wurm zuerst dran.

Insider-Bedrohung meint einen Angreifer mit legitimem Zugang innerhalb der eigenen Organisation. Der xz-utils-Fall zeigt die Grauzone: Der Angreifer war Insider des Open-Source-Projekts, aber Außenstehender für jede Distribution, die das Paket nutzte. Für dich als Anwender ist es ein Supply Chain Attack, für das Projekt ein Insider-Fall.

Broken Access Control (A01) beschreibt fehlende oder falsche Rechteprüfung innerhalb deiner Anwendung. Ein Supply Chain Attack kann solche Lücken ausnutzen oder umgehen, etwa wenn eine Erweiterung mit Shop-Rechten die Sandbox verlässt, ist aber ein eigener Angriffsweg, der den Code von außen in dein System bringt.

Häufige Fragen

Reicht ein Dependency-Scanner wie npm audit oder Dependabot gegen Supply-Chain-Angriffe?

Nein. Diese Werkzeuge gleichen Versionen mit bekannten CVEs ab. Ein kompromittiertes Paket hat in den ersten Stunden oder Tagen keine CVE und erscheint als harmlose neue Version. Scanner sind nötig für den Teil „veraltete Komponenten“, aber gegen Würmer wie Shai-Hulud helfen Lockfile, Karenzzeit, abgeschaltete Install-Skripte und eine SBOM, mit der du im Ernstfall schnell prüfen kannst, ob du betroffen bist.

Betrifft das Thema auch einen Shopware-Shop ohne eigenes Node.js-Projekt?

Ja, auf zwei Wegen. Erstens läuft der Build der Storefront und der Administration selbst über npm, auch wenn du nie eine Zeile JavaScript schreibst. Zweitens sind Apps und Plugins deine Lieferkette: Sie laufen mit den Rechten deines Shops, und Advisories wie der App-Script-Sandbox-Escape vom August 2026 zeigen, dass die Sandbox keine Garantie ist. Halte die Zahl der Erweiterungen klein und ihre Versionen aktuell.

Was ist der erste Schritt, wenn ich heute anfangen will?

Erzeuge eine SBOM für jedes produktive Projekt und stelle die CI auf npm ci --ignore-scripts um; beides dauert einen Nachmittag. Danach aktivierst du Zwei-Faktor-Authentifizierung ohne Bypass-Tokens auf allen Registry- und GitHub-Konten und führst eine Karenzzeit für neue Versionen ein. Erst wenn das steht, lohnen sich Signaturprüfung und Provenance als nächste Stufe.