Die meisten Sicherheitsteams aktivieren die EDR-Option, aktivieren die Proxy-Option und machen dann weiter. Gegen Malware aus der Lieferkette bieten beide jedoch keinen nennenswerten Schutz, da sie für ein anderes Problem entwickelt wurden.
Herkömmliche Malware schleicht sich meist unbemerkt auf einen Rechner ein, während Malware in der Lieferkette gewollt eingeladen wird. Der Entwickler führt npm install, und der Schadcode wird mit uneingeschränkten Ausführungsrechten ausgeführt. Diese Umkehrung macht beide Tools auf der Konzeptionsebene unbrauchbar.
Warum EDR Malware übersieht
EDR überwacht Prozesse auf verdächtiges Verhalten: ungewöhnliche Systemaufrufe, unerwartete Eltern-Kind-Beziehungen, bekannte Signaturen von Schadsoftware. Es fragt: „Verhält sich dieser Prozess wie Malware?“
Das Problem ist, dass Supply-Chain-Malware innerhalb vertrauenswürdiger Laufzeitumgebungen ausgeführt wird und dabei genau das tut, was diese Laufzeitumgebungen ohnehin ständig tun. Ein Skript, das nach der Installation `.env`-Dateien ausliest und deren Inhalt per POST an einen Angreifer sendet, sieht genauso aus wie ein Build-Tool, das Anmeldedaten abruft, um Code bereitzustellen. Beides sind node oder python Dateien lesen und HTTP-Aufrufe ausführen. Die Systemaufrufe und die Netzwerkaufrufe sind identisch. EDR verfügt über keinen Kontext, der anzeigt, dass der eine legitim ist und der andere nicht.
Im März 2026 kapern Angreifer das npm-Konto des Hauptbetreuers von axios, einem Paket mit etwa 100 Millionen Downloads pro Woche. Sie griffen nicht in den Quellcode ein. Stattdessen fügten sie eine neue Abhängigkeit hinzu, deren einzige Aufgabe darin bestand, ein plattformübergreifendes RAT herunterzuladen und sich anschließend selbst zu löschen. Für einen Prozessmonitor war dies nicht von einem regulären npm-Installationsvorgang zu unterscheiden. Es löst eine Abhängigkeit auf, führt einen Hook aus und stellt eine HTTP-Anfrage.
Zwei Monate später, Drei Versionen von „durabletask“, einem Python-Paket im Azure-Ökosystem von Microsoft, waren mit einer Hintertür versehen. Der Text umfasste etwa zehn Zeilen __init__.py. Der Code ruft eine Datei ab und führt sie in einem Unterprozess aus, wobei Ausnahmen unterdrückt werden. In der zweiten Phase wurden Anmeldedaten von AWS, Azure, GCP, Kubernetes und Vault abgegriffen und anschließend über SSM auf andere Instanzen sowie über kubectl exec, wobei die Anmeldedaten des Opfers verwendet und dessen eigene Cloud-APIs aufgerufen wurden. Auf Hosts mit israelischen oder iranischen Ländereinstellungen führte ein „One-in-Six“-Roll den Befehl „rm -rf /*“ aus. Keine fremde Binärdatei, kein ungewöhnliches Ziel. EDR verfügt über kein Modell für den Fall, dass das Paket selbst die Bedrohung darstellt.
Lieferkettenangriffe dieser Ebene sind deshalb so gefährlich, weil die bösartige Nutzlast als normales Verhalten erscheint. Es gibt keine Anomalien, die erkannt werden könnten, denn das Ziel besteht gerade darin, sich im Rauschen zu verstecken – oder in diesem Fall selbst das Rauschen zu sein.
Warum Proxys das übersehen
Ein Proxy im Datenpfad kann das Herunterladen von Paketen abfangen und diese mit als schädlich bekannten Paketen abgleichen. Theoretisch funktioniert das. Das Problem ist jedoch der Teil „im Datenpfad“.
Remote- und Unternehmens-Proxys sind Opt-in-Einstellungen auf den Computern der Entwickler. Entwickler arbeiten von zu Hause aus, in Cafés oder über das WLAN im Hotel. Sie installieren Tools, die die Proxy-Einstellungen des Systems umgehen. VS Code verwaltet den Download seiner eigenen Erweiterungen. npm, pip und cargo verfügen über eigene HTTP-Clients. Viele CLI-Tools und Sprach-Runtimes ignorieren HTTP_PROXY vollständig, sofern nicht ausdrücklich anders konfiguriert. Und wenn ein Tool aufgrund des Proxys nicht mehr funktioniert, deaktivieren die Entwickler den Proxy, beheben den Fehler im Tool und vergessen, ihn wieder zu aktivieren.
Fälle wie diese kommen täglich vor. Ein Entwickler installiert um 23 Uhr von seinem privaten Rechner aus eine kompromittierte VS-Code-Erweiterung. Ein CI-Runner lädt eine manipulierte Abhängigkeit außerhalb des Unternehmensnetzwerks herunter. Keine dieser Installationen läuft über den Proxy. Der Scan wird nie ausgeführt. Die Überprüfung, die das hätte aufdecken sollen, war schlichtweg nicht vorhanden.
Was tatsächlich funktioniert
Sowohl EDR als auch Proxys lösen konkrete Probleme im Zusammenhang mit den Bedrohungen, für deren Abwehr sie entwickelt wurden, und sind nach wie vor von großem Nutzen. Sie decken lediglich nicht die für Entwickler spezifische Angriffsfläche in der Lieferkette ab.
Diese Oberfläche benötigt eine Komponente, die direkt auf dem Rechner selbst läuft, die bei der Installation erkennt, was die Pakete tun, und die unabhängig von der Netzwerkkonfiguration stets verfügbar ist. Genau dafür haben wir Aikido Protection“ entwickelt. Erfahren Sie in diesem Blog, wie verschiedene Unternehmen „Device Protection“ einsetzen, um die Rechner ihrer Entwickler zu schützen.
Wenn Sie sich ein umfassenderes Bild davon machen möchten, was herkömmliche Endpoint-Tools auf Entwickler-Rechnern übersehen, finden Sie in diesem Artikel Informationen zur MDM-Variante dieses Problems.
