Supply Chain Attacks im Web – 10 Methoden, Angriffe im npm-Ökosystem zu vermeiden

Hinweis: Dieser Post ist auch auf auf Englisch 🇬🇧 verfügbar.

Das Jahr 2026 steht noch deutlicher als das Vorjahr im Schatten weitreichender und tiefgreifender Supply Chain Attacks (SCAs). Überspitzt formuliert vergeht kein Tag, an dem in Softwareentwicklerkreisen nicht eine neue Meldung über ein weiteres infiziertes Softwarepaket aufkommt, welches das Potential hat, eigene Lösungen und Infrastrukturen anzugreifen. Eine SCA, also grundlegend der Prozess, ohne eigenes Zutun via externe Abhängigkeiten als Einfallstor von bösartigen Akteuren angegriffen zu werden, war noch vor einigen Jahren eine eher theoretisch betrachtete Randerscheinung. Heutzutage hat sich das Thema allerdings zu einer omnipräsenten und ernstzunehmenden Gefahr in der Softwarebranche entwickelt.

Konkret veranschaulicht wird diese Entwicklung beispielsweise in einem Bericht des Unternehmens Sonatype (Abbildung 1). Aufgezeigt wird die Entwicklung der von Sonatype entdeckten bösartigen Softwarepakete – vom Beginn der Aufzeichnungen im Jahr 2019 bis einschließlich 2025. Das Jahr 2025 endete mit über 1,2 Millionen entdeckten Paketen – und jedes davon eine individuelle Möglichkeit, unbeabsichtigt ein eigenes System zu infizieren.

Abbildung 1: Entwicklung bösartiger Softwarepakete (2019 – 2025)
Quelle: (Sonatype, 2025)

Besonders besorgniserregend ist der beinahe exponentielle Anstieg solcher infizierten Pakete. Der größte Anteil ist hier dem npm-Ökosystem zuzuschreiben. Allein im Jahr 2025 waren 99% der von Sonatype entdeckten Pakete auf npm zu finden. Kombiniert mit der Vielzahl von solchen Paketen, die in einem durchschnittlichen Projekt im Web- oder Node.js-Umfeld installiert werden, stellt sich hier die Frage, wie sich die unmittelbare Gefahr einer SCA bestmöglich reduzieren lässt. Wenngleich sich bereits vorab sagen lässt, dass die Gefahr niemals vollständig unterbunden werden kann, solange externe Abhängigkeiten verwendet werden, so können doch selbst einfache Maßnahmen und Praktiken bereits helfen, die Chance eines solchen Vorfalls drastisch zu reduzieren.

SCA – Eine Einordnung

Grundsätzlich folgt eine SCA einem einzigen Ziel: Dem Ausführen von Schadsoftware auf einem oder mehreren Zielsystem(en), um arbiträre Ziele wie beispielsweise das Installieren von Crypto Minern bis hin zum Stehlen von geheimen Daten zu erreichen. Was SCAs von anderen Angriffsarten unterscheidet, ist die Art der Einschleusung der Schadsoftware. Anstatt ein Zielsystem direkt, beispielsweise über eine bekannte Schwachstelle, zu infiltrieren, nutzen SCAs typischerweise einen Umweg, indem sie Abhängigkeiten eines Systems infizieren. Genau diese Eigenschaft macht SCAs derartig perfide – Abhängigkeiten, denen man bereits seit langer Zeit sein Vertrauen schenkt, werden plötzlich zum Vehikel von Schadcode, der das eigene System und potenziell dessen Nutzer angreift.

Die Arten und Weisen, auf die ein Paket zum „Patient Zero“, also eben initial infiziert und zur Quelle einer SCA werden kann, sind vielfältig. Bereits 2020, also sogar vor dem aktuellen thematisierten Anstieg, publizierten Ohm, Plate, Sykosch, & Meier (2020) eine wissenschaftliche Analyse von bereits damals aufgetretenen SCAs im Open-Source Umfeld. Abbildung 2 zeigt die von den Autoren klassifizierten Angriffspfade auf – von der Neuerstellung bösartiger Pakete bis zur Kompromittierung eines bestehenden Pakets. Die dargestellten Methoden sind bis heute, knapp sechs Jahre nach Veröffentlichung des Papers, noch akkurate Beschreibungen, wie eine SCA Zielsysteme infizieren kann.

Abbildung 2: Mögliche Angriffspfade zum Infizieren von Paketen
Quelle: Ohm, Plate, Sykosch, & Meier (2020)

So erlangte beispielsweise im Jahr 2018 das Thema SCA durch den „event-stream“ Angriff erstmals größeres Aufsehen. Zusammengefasst wurde damals das populäre npm-Paket event-stream durch einen bösartigen Pull Request („Pull Request (as contributor)“) dahingehend erweitert, dass das Paket selbst von einem weiteren, speziell präparierten und bösartigen Paket namens flatmap-stream abhängig gemacht wurde. Die Auswirkungen betrafen gezielt die Bitcoin Wallet Copay und verdeutlichten bereits damals, wie schnell sich Schadsoftware gezielt per SCA in ein Zielsystem einschleusen lässt. Gegen Ende des Jahres 2025 wurde der Name „Shai-Hulud“ ein Sammelbegriff und Ablaufplan für SCAs mit der Fähigkeit sich nach Infektion eines Pakets selbstständig weiterzuverbreiten und somit eine Kette weitere Pakete zu infizieren. Mit bis zu 500 infizierten Paketen in wenigen Tagen, prominenten Opfern, wie @tanstack/router oder Mistral und wiederkehrenden Angriffswellen in verschiedenen Formen und durch verschiedene Akteure ist Shai-Hulud eine im Vergleich zu event-stream weitaus komplexere und weiterentwickelte Version einer SCA. Im Falle von TanStack begann allerdings auch diese Welle beispielsweise durch einen in Abbildung 2 gezeigten Angriffspfad – konkret durch die Kompromittierung eines Build-Systems und im Folgenden durch automatisch bei der Installation eines kompromittierten Pakets ausgeführter Skripte.

Grundsätzlich zeigt eine Analyse von bereits geschehenen SCAs auf, dass ein Verständnis für die Art und Weise, wie andere Abhängigkeiten und Systeme in der Vergangenheit kompromittiert werden konnten, dabei helfen kann, sich selbst vor einer SCA zu schützen. Im Folgenden werden hier 10 konkrete Methoden vorgestellt, die jeder Entwickler im Web Development Umfeld nutzen kann, um persönlich und auch für ein etwaiges Team die Chance einer SCA zu reduzieren.

10 Methoden zur Vermeidung von SCAs im npm Ökosystem

ℹ️ Anmerkung

Sämtliche der hier genannten Beispiele und Konfigurationen nutzen npm als zugrundeliegenden Paketmanager, da npm typischerweise der am häufigsten verwendete unter den zur Verfügung stehenden Tools ist. Andere Optionen wie Yarn oder pnpm unterstützen in den meisten Fällen allerdings auch dieselben oder zumindest äquivalente Optionen – in manchen Fällen sogar granularer oder ausgeprägter.

1 Lifecycle Scripts deaktivieren

Lifecycle Scripts, auch Install Scripts genannt, sind Skripte, die von einem npm-Paket zu bestimmten Zeitpunkten, beispielsweise bei der Installation des Pakets, automatisch ausgeführt werden. Diese Skripte werden von wohlwollenden Paketen für durchaus sinnvolle Zwecke verwendet (unsere eigene piral-cli nutzt beispielsweise das postinstall Skript zur automatischen Generierung von nützlichen Codedateien). Problematisch werden diese Skripte allerdings bei bösartigen Paketen, denn grundsätzlich kann jedes Paket über Lifecycle Skripte jeden beliebigen Code ausführen. Diese Möglichkeit öffnet ein riesiges Einfallstor für etwaige bösartige Pakete – beispielsweise kann bei jeder Installation eines Malwarepakets dieses auf dem Zielsystem beliebigen Schadcode ausführen.

Auch wenn Lifecycle Scripts nützlich sein können – das von ihnen ausgehende Risiko überwiegt meist den möglichen Nutzen. In den meisten Fällen macht es Sinn, das Ausführen solcher Skripte und damit das potenzielle Ausführen von Schadcode im Kern zu unterbinden. Möglich gemacht wird dies in npm über die ignore-scripts Konfiguration. Diese kann lokal für den aktuellen User/den aktuellen PC, oder auch global für das gesamte Entwicklerteam über folgende Wege deaktiviert werden:

Abbildung 3: Deaktivieren von Lifecycle Scripts per CLI

Abbildung 4: Deaktivieren von Lifecycle Scripts für ein npm-basiertes Projekt

---

ℹ️ Anmerkung

Oft lohnt es sich, diese (und auch kommende) Einstellungen doppelt vorzunehmen, also sowohl für die aktuelle Maschine als auch via .npmrc für ein gesamtes Projekt. Auf diese Weise wird sowohl die eigene Entwicklungsumgebung als auch diejenigen von Teammitgliedern oder beispielsweise automatisierten Pipelines geschützt.

---

ℹ️ Anmerkung

Mit npm Version 12 wurden Lifecycle Scripts standardmäßig deaktiviert. Ein manuelles Deaktivieren könnte somit nicht mehr notwendig sein. Projektweite Konfigurationen via .npmrc können allerdings zumindest übergangsweise sinnvoll bleiben, solange nicht beispielsweise alle Teammitglieder oder Pipelines npm in Version 12 verwenden.

2 Versionen festlegen (pinnen)

npm bietet beim Referenzieren bestimmter Abhängigkeitsversionen verschiedene Versionsauflösungsstrategien an. Für eine Abhängigkeit kann man:

1. Eine exakte Version anfragen (z.B. 1.2.3).
2. Die neuste Version innerhalb einer „Major-Version“ anfragen (z.B. die neuste Version, die mit 1 startet).
3. Die neuste Version innerhalb einer „Minor-Version“ anfragen (z.B. die neuste Version, die mit 1.2 startet).
4. Immer die neueste Version anfragen.

Hierfür wird innerhalb einer package.json Datei spezielle Syntax unterstützt:

Abbildung 5: npm Syntax für Versionierung

Der Standard bei der Neuinstallation eines Pakets ist Option 2, also eine Versionierungsstrategie, bei der die zu installierende Version eines Pakets nicht zwangsläufig final bekannt ist! Diese „dynamische“ Versionierung stellt im Kontext einer SCA eine Gefahr dar. Falls eine kompromittierte Version eines Pakets innerhalb eines dynamischen Versionsbereichs veröffentlicht wird, kann dieses Paket automatisch installiert werden.

Gegen solche Fälle kann man sich mittels folgender drei Punkte schützen:

1. Aktives „pinnen“ von installierten Abhängigkeiten.
2. Verwenden von Lockdateien (package-lock.json).
3. Verwenden von „clean installs“ (npm ci Befehl) zum Installieren von Paketen.

Pinnen von Abhängigkeiten bezeichnet Option 1, also das Spezifizieren einer exakten Paketversion. Dadurch wird die Liste von first-level Abhängigkeiten innerhalb eines Projekts bis zur nächsten, manuell durchgeführten, Versionsänderung stabilisiert. Durchführen kann man ein „Pinning“ durch das Entfernen der speziellen Syntax innerhalb einer package.json Datei (siehe Abbildung 6).

Abbildung 6: Pinning von Versionen

Wichtig: Pinnen von Versionen stabilisiert nur direkt installierte Abhängigkeiten. Transitive Abhängigkeiten, also Pakete, die wiederum von anderen Paketen referenziert werden, können dennoch dynamisch aufgelöst werden und somit auch zum Einfallstor einer SCA werden.

Um dieses Problem zu umgehen, kann man Punkt (2) und (3) anwenden. Lockdateien definieren den exakten Abhängigkeitsbaum, der bei einer Versionsänderung eines Pakets initial installiert wird. Der npm ci Befehl installiert, im Vergleich zu npm i, auch nur exakt die Versionen, die in der package-lock.json Datei genannt sind. package-lock.json Dateien sollten deswegen immer innerhalb eines Projekts und Teams geteilt werden, also beispielsweise als Teil eines Coderepositories eingecheckt werden.

3 min-release-age

Viele SCAs werden heutzutage sehr schnell von automatisierten, häufig KI-gestützten Analysen und Anbietern in kurzer Zeit gefunden und dann, nach Entdeckung, schnell von npm entfernt. Oft sind kompromittierte Pakete somit nur für einen kurzen Zeitraum zur Installation verfügbar.

An diesem Punkt setzt die Konfigurationsoption min-release-age an. Mithilfe dieser Option lässt sich ein Mindestalter einstellen, welches ein Paket zwingend erreicht haben muss, um von npm installiert werden zu können. Ein Zeitraum von beispielsweise drei bis sieben Tagen könnte bereits helfen, eine potenzielle Liste von kompromittierten Paketen von der Installation auszuschließen. Diese Option kann, analog zu Lifecycle Scripts, User-, Maschinen- oder auch Projektweit gesetzt werden:

Abbildung 7: Konfigurieren von min-release-age per CLI

Abbildung 8: Konfigurieren von min-release-age für ein npm-basiertes Projekt

4 Bewusste Aktualisierungen

Neue Versionen von Abhängigkeiten werden im npm-Ökosystem fast täglich veröffentlicht. Oft werden Abhängigkeiten in Projekten direkt, bzw. sehr schnell aktualisiert. Aus denselben Gründen wie bei min-release-age kann es aber auch Sinn machen, Versionsupdates ausschließlich bewusst durchzuführen und, falls möglich, sogar zu vermeiden oder so lange zu verzögern, dass ein zeitlicher Schutzeffekt gegen SCAs entsteht. Nicht jedes Versionsupdate bringt Vorteile für ein Projekt. Werden in einer Abhängigkeit beispielsweise Probleme eines Features behoben, das von einem Projekt nicht verwendet wird, kann ein Update durch die SCA-Thematik sogar mehr Risiken als Vorteile bergen. Ein bewusster Umgang mit neuen Versionen von npm-Paketen und deren Updates kann eine SCA im eigenen Umfeld verhindern.
Natürlich muss sichergestellt werden, dass Updates auf neue Versionen auch nicht zu lange hinausgezögert werden. Wichtige Sicherheitsupdates oder auch neue Major-Versionen sollten, sofern möglich, zeitnah integriert werden, um etwaige spätere Sicherheitslücken und lang andauernde Updateprozesse zu verhindern. Der richtige Prozess für ein konkretes Paket ist eine situationsabhängige Balance.

5 Sind Abhängigkeiten notwendig?

Insbesondere im npm-Ökosystem gibt es eine Vielzahl von (Kleinst-)paketen, die häufig von Projekten als Unterstützung verwendet werden. Ein kurioses Beispiel machte vor einigen Jahren Schlagzeilen, als der für das Paket left-pad zuständige Maintainer das Paket von npm löschte. left-pad ist ein npm-Paket mit einer einzigen, wenigen Zeilen langen Hilfsfunktion. Das Löschen führte zu heftigen Disruptionen in vielen, auch großen und bekannten, Projekten. Die damals laut hörbare Debatte, wieso solche Pakete überhaupt erst von Projekten verwenden werden und solche kleinen Hilfsfunktionen nicht direkt auf Projektebene selbst entwickelt und verwaltet werden, ist auch aus der Blickrichtung der Prävention von SCAs interessant. Häufig ist es möglich, zumindest einen kleinen Teil von Abhängigkeiten schlichtweg zu entfernen, beziehungsweise durch selbstverwalteten Code zu ersetzen, und somit das Risiko einer SCA zu mildern. Dies gilt insbesondere im heutigen Zeitalter der KI, dank deren Hilfe der Aufwand für das Schreiben und die Pflege solcher Hilfsfunktionen drastisch gesunken ist. Aber nicht nur der Blick auf Kleinstpakete lohnt sich: Das JavaScript Ökosystem entwickelt sich konstant weiter und erlaubt teilweise auch das Entfernen von größeren Paketen. Ein Beispiel hierfür ist die kommende Temporal API – ein nativer Ersatz für vom Umfang größere Pakete wie beispielsweise moment oder dayjs. Der regelmäßige Blick auf und das Hinterfragen der Verwendung von Abhängigkeiten kann sich lohnen!

6 Umgang mit Registries

Oft werden innerhalb eines Unternehmens private, also von außen nicht zugängliche, npm-Registries und Pakete verwendet. Auch in diesem Bereich gibt es gängige Einfallstore für eine SCA. Einem Angreifer kann es, beispielsweise über einen Dependency Confusion Angriff, möglich werden, Systeme trotz internen Registries und Paketen zu infizieren.

Allgemein gibt es zwei leicht umzusetzende Punkte, die einen solchen Angriff verhindern können:

1. Verwenden von Scopes: npm-Pakete können mit einem Scope (einem Präfix im Format @scope/PAKET_NAME) beginnen. Scopes können in einer .npmrc Datei mit einer bestimmten npm-Registry verknüpft werden (siehe Abbildung 9). Über eine solche Konfiguration kann forciert werden, dass npm die Pakete ausschließlich aus der gewollten, privaten Registry herunterlädt.
2. Registrieren von Scopes auf npmjs.com: Private npm-Registries spiegeln oft die öffentliche npm-Registry und laden von dort Pakete herunter, die intern nicht gefunden werden können. Wenn intern eigene Paket Scopes verwendet werden und dieser Scope nicht in der öffentlich npm Registry registriert ist, könnte ein möglicher Angreifer diesen Scope registrieren, unter diesem Scope ein kompromittiertes Paket mit einer hohen Version veröffentlichen und somit die interne Registry dazu bewegen, dieses bösartige Paket zu spiegeln. Um dieses Einfallstor zu schließen, sollten intern verwendete Scopes nach Möglichkeit auch in der öffentlichen npm-Registry registriert werden. Unter registrierten Scopes können, außerhalb des Eigentümerkreises, keine weiteren Akteure Pakete veröffentlichen.

Abbildung 9: Konfiguration von Scopes

7 Auditing

Auditing bezeichnet das automatische Scannen von verwendeten Abhängigkeiten auf Schwachstellen. Ein automatisiertes und regelmäßiges Auditing, beispielsweise als fester Bestandteil der Buildpipeline eines Projekts, kann nach Bekanntwerden eines kompromittieren Pakets dabei helfen, schnell auf die Verwendung im eigenen Projekt zu reagieren. Auditing zielt generell eher auf die Mitigation einer SCA ab, also auf die Entdeckung bereits verwendeter, schädlicher Pakete im eigenen Projekt.

Anbieter und Tools für automatisierte Scans, sowohl kostenlos als auch kommerziell, gibt es viele. Bereits fest in npm integriert ist der npm audit Befehl der vulnerable Abhängigkeiten mithilfe der GitHub Advisory Datenbank findet und auflistet. Als Teil eines CI/CD Systems ausgeführt kann npm audit Pipelines und Builds direkt stoppen, wenn kritische Abhängigkeiten entdeckt wurden. Die durchgängige Integration von npm audit als Minimum in sämtliche Build Pipelines macht, sofern unterstützt, in den allermeisten Fällen Sinn.

8 Sandboxing und Isolation

Ebenfalls im Bereich der Mitigation angesiedelt ist das Thema Sandboxing und Isolation. Als Entwickler arbeitet man häufig an mehreren Projekten, beziehungsweise hat zumindest häufig die Dateien verschiedener Projekte auf einem System installiert. Oft bedeutet das, dass zusätzlich zu einem Projekt auch Geheimnisse (Secrets) und/oder Anmeldedaten (Credentials) anderer Projekte auf der Maschine verfügbar sind. Dies kann, ohne Isolation der verschiedenen Projekte, dazu führen, dass im Falle der Kompromittierung eines Projekts durch eine SCA auch geheime Daten eines anderen Projekts gestohlen werden – von allgemein auf dem System gefundenen Secrets einmal komplett abgesehen.

Um dem entgegenzuwirken kann es sinnvoll sein, Projekte isoliert/abgeschirmt von anderen zu entwickeln. Bei einem isolierten Projekt kann ein SCA immerhin nur die dem Projekt zur Verfügung gestellten Daten finden – idealerweise ein wesentlich kontrollierbarer Ausgangspunkt für Reaktionen auf einen solchen Angriff. Möglichkeiten der Isolation gibt es viele, beispielsweise das Entwickeln innerhalb einer projektspezifischen VM, in Dev Containern oder auch das Verwenden von Produkten wie GitHub Codespaces.

9 KI-Agenten

KI-Agenten haben sich in Entwicklerkreisen mittlerweile als Standardwerkzeug etabliert. Dennoch, oder gerade deswegen, bieten diese eine Angriffsfläche im Rahmen von SCAs. Sonatype berichtet beispielsweise, dass KI-Agenten nachweislich dazu bewegt werden können, eine kompromittierte Abhängigkeit zu installieren. Außerdem wird berichtet, wie Angreifer ihre Angriffspfade mittlerweile verstärkt auch auf KI-Agenten ausrichten, beispielsweise durch Methoden wie Typosquatting bei Paketnamen.

Als Entwickler sollte man sich zumindest die Frage stellen, inwiefern man einem installierten KI-Agenten beim Verwalten von Abhängigkeiten vertrauen und überlassen möchte. Von komplettem Entzug der Abhängigkeitsverwaltungsaufgaben bis hin zur vollständigen Erlaubnis derselben, beispielsweise in Kombination mit starker Projektisolation – beide Optionen können situationsabhängig valide sein. Bewusst sein sollte man sich aber zumindest darüber, dass auch KI-Agenten, und somit unmittelbar der eigentlich dahinterstehende Nutzer, Opfer einer SCA werden können.

10 Maintainer – 2FA & Trusted/Staged Publishing

Dieser Punkt ist zugeschnitten auf Maintainer von npm-Paketen. npm reagierte selbst auf die rasant steigende Zahl infizierter Pakete und hat in der vergangenen Zeit einige Optionen entwickelt, mit denen sich potenziell verhindern lassen kann, dass ein kompromittiertes Paket im eigenen Namen veröffentlicht wird:

1. Zwei-Faktor-Authentifizierung (2FA): 2FA ist für das Veröffentlichen von Paketen beinahe schon Pflicht – das Einrichten eines zweiten Faktors schützt vor der Übernahme des eigenen Accounts, und damit der Fähigkeit, neue Versionen eines Pakets hochzuladen.
2. Trusted Publishing: npm unterstützt den Trusted Publishing Standard. Dieser erlaubt es, ein Paket direkt aus einer Build Pipeline und komplett ohne manueller Verwaltung von langlebigen Authentifizierungstokens zu veröffentlichen – stattdessen werden automatisiert kurzlebige Token ausgestellt. Neben automatischen Verbesserungen bei der Benutzerfreundlichkeit (Token können nicht mehr versehentlich ablaufen und Pipelines fehlschlagen lassen) können die von Trusted Publishing verwendeten Token schwieriger abfließen, beziehungsweise, aufgrund ihrer Kurzlebigkeit, insgesamt schwerer von böswilligen Akteuren verwendet werden.
3. Staged Publishing: Relativ neu ist die Möglichkeit, Pakete auf npm vor der finalen Veröffentlichung zu „stagen“. Im Vergleich zu einer direkten Veröffentlichung muss ein Paket hier, beispielsweise nach dem Staging durch eine Buildpipeline, explizit und durch 2FA verifiziert von einem Maintainer freigegeben werden, bevor es als neue Version erscheint und installiert werden kann.

Kombiniert bieten diese drei Optionen einen starken Schild sowohl zur Prävention als auch zur Mitigation einer möglichen SCA. Einzeln betrachtet sind die Maßnahmen aushebelbar – so unterband Trusted Publishing allein beispielsweise nicht die SCA auf TanStack. Eine Kombination aus Trusted und Staged Publishing hätte hier rückblickend vielleicht einen anderen Verlauf erwirkt.

Ausblick

Kann man mit Hilfe der hier genannten Methoden eine etwaigen SCA im eigenen Umfeld komplett verhindern? Diese Frage muss mit einem klaren „Nein“ beantwortet werden. Die aufgezeigten Methoden können eine SCA zwar im Besten Fall unterbinden, oder zumindest deren Auswirkungen mildern, aber einen 100%igen Schutz stellen auch sie nicht dar. Der komplexe Angriff auf TanStack verdeutlicht, wie feindliche Akteure bereits heute komplizierte Methoden entwickeln und anwenden, um Schadsoftware tief im Wald der Softwareabhängigkeiten zu verstecken. So paranoid es klingen mag: bei der heutigen Entwicklung sollte man sich nicht mehr fragen, ob man von einer SCA getroffen wird, sondern wann – und entsprechende Präventions- und Reaktionsmaßnahmen vorbereiten. Die meisten der oben genannten Methoden zielen auf Prävention und sind, auch wenn sie in diesem Artikel auf das npm-Ökosystem zugeschnitten sind, auch in anderen Sprachen und Umfeldern wie Python/Pip oder C#/NuGet anwendbar. Zusätzlich zur Prävention ist es allerdings auch sinnvoll, bereits für den Worst-Case vorzuplanen und, idealerweise, einen Incident-Response-Prozess vorzubereiten, der im Falle einer erfolgreich durchgeführten SCA durchlaufen werden kann. Am Ende gilt: Wachsamkeit und ein aktiver Blick auf die eigenen Abhängigkeiten sind der beste Schutz. Wer SCAs als ernstzunehmende Gefahr begreift und danach handelt, ist vor diesen nachhaltig besser geschützt.

Quellen

• Ohm, M., Plate, H., Sykosch, A., & Meier, M. (2020). Backstabber’s Knife Collection: A Review of Open Source Software Supply Chain Attacks. International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment (S. 23-43). Springer, Cham.
• Sonatype. (2025). Open Source Malware at the Gate - The Evolving Software Supply Chain Attack Surface.