Erkennung und Prävention von Malware in modernen Software-Supply-Chains

Open-Source-Abhängigkeiten sind das Rückgrat moderner Software – aber sie sind auch eine wichtige Angriffsfläche. Böswillige Akteure nehmen zunehmend Paketregister und Entwickler-Workflows ins Visier, um Malware einzuschleusen, die sofort nach der Installation einer Abhängigkeit ausgeführt wird. In diesem Beitrag wird erläutert, wie diese Malware-Kampagnen in der Lieferkette funktionieren, warum herkömmliche Scanner sie übersehen und welche praktischen Abwehrmaßnahmen Sie heute ergreifen können.

Die Bedrohungslage: Warum die Lieferkette ein bevorzugtes Ziel ist

Bedrohungsakteure – darunter auch staatlich geförderte Gruppen – nutzen Open-Source-Ökosysteme aktiv aus. Die Angriffe reichen von kompromittierten Maintainer-Konten bis hin zu automatisierten Würmern, die sich selbstständig über Registries verbreiten. Die Auswirkungen werden durch die weit verbreitete Wiederverwendung von Paketen noch verstärkt: Ein einziges kompromittiertes Modul kann millionen- oder milliardenfach über Projekte und Organisationen hinweg heruntergeladen werden.

Wie Angreifer Malware einschleusen

Es gibt mehrere gängige Techniken, mit denen Angreifer bösartigen Code in Ihre Builds einschleusen. Wenn Sie diese Muster verstehen, lassen sie sich leichter erkennen und blockieren.

• Kontoübernahme – Ein Angreifer phischt einen Maintainer oder stiehlt Entwickler-Token für Registries wie npm oder PyPI und veröffentlicht dann Malware in einem vertrauenswürdigen Paket. Wenn dieses Paket installiert wird, zieht jeder Verbraucher den bösartigen Code herein.
• Typo-Squatting – Angreifer veröffentlichen ein Paket mit einem Namen, der einem beliebten Modul sehr ähnlich ist (z. B. CCTVX vs. CCXT). Ein einfacher Tippfehler während der Installation kann dazu führen, dass Sie ein bösartiges Paket anstelle des legitimen Pakets herunterladen.
• Verwirrung bei Abhängigkeiten – Wenn ein interner Paketname nicht streng auf eine private Registrierung beschränkt ist, bevorzugen Paketmanager möglicherweise ein öffentliches Paket mit demselben Namen. Angreifer veröffentlichen ein öffentliches Paket, das Ihre interne Abhängigkeit überschreibt.
• Halluzination Squatting – Große Sprachmodelle erfinden manchmal Abhängigkeiten, die gar nicht existieren. Angreifer finden heraus, was LLMs häufig halluzinieren, veröffentlichen diese erfundenen Pakete und warten auf Opfer, die den generierten Code in Projekte kopieren.

Reale Beispiele, die zeigen, wie weit verbreitet dies ist

Es gab viel beachtete Vorfälle, bei denen weit verbreitete Pakete kompromittiert wurden, was zu einer massiven Gefährdung des gesamten Ökosystems führte. In anderen Fällen stahlen sich selbst verbreitende Würmer Entwickler-Token, um die Infektion automatisch auf weitere Pakete zu übertragen – wodurch aus einer einzigen Kompromittierung eine sich ausweitende Kampagne wurde.

Warum Malware schlimmer ist als eine typische Sicherheitslücke

Im Gegensatz zu einer Schwachstelle, die erst entdeckt und ausgenutzt werden muss, wird Malware gezielt entwickelt, um Schaden anzurichten. Viele schädliche Pakete enthalten Skripte, die vor oder nach der Installation ausgeführt werden, sobald die Abhängigkeit installiert ist. Zu den häufigsten schädlichen Verhaltensweisen gehören:

• Kontaktieren eines Command-and-Control-Servers (C2), um Daten zu exfiltrieren oder Befehle zu empfangen
• Installation von Backdoors oder Erlangung der Remote-Codeausführung auf Build-Systemen
• Diebstahl von Paket-Maintainer-Tokens zur Verbreitung über Registries

Das Ausmaß: Tausende bösartige Pakete jeden Monat

Malware in Registern ist keine Seltenheit. Forschungsteams, die Register überwachen, finden jeden Monat Tausende von bösartigen Paketen. Die meisten sind nur wenige Stunden lang aktiv, bevor sie entfernt werden, was bedeutet, dass die Erkennung schnell und kontinuierlich erfolgen muss.

Malware in Echtzeit erkennen

Da bösartige Releases nur für einen sehr kurzen Zeitraum live sein können, müssen Erkennungstools nahezu in Echtzeit arbeiten und in die Arbeitsabläufe der Entwickler integriert sein. Zwei wichtige Funktionen sind dabei unerlässlich:

• Echtzeit Bedrohungsaufklärung – Eine Datenbank mit schädlichen Paketen, die kontinuierlich aktualisiert wird, sodass Installationen anhand der neuesten Indikatoren überprüft werden können.
• Überprüfungen auf Installationsniveau – Eine kleine, reibungslose Hülle um Paketmanager, die Pakete vor ihrer Installation validiert, ohne den Arbeitsablauf der Entwickler zu stören.

Tools, die sich im Installationspfad befinden (z. B. Wrapping-Installationen von npm, yarn oder pip), sind besonders effektiv, da sie Malware blockieren können, bevor sie einen Build oder einen Entwicklerrechner befällt.

Wie Bedrohungsaufklärung bösartige Pakete erkennen

Das Aufspüren von Malware in der Lieferkette ist schwierig, da jeder Indikator auch harmlos sein kann. Beispiele für verdächtige Indikatoren sind starke Base64-Verschleierung, ausgehende Anrufe an ungewöhnliche Domains und unsichtbare Unicode-Zeichen, die in den Code eingebettet sind. Jeder dieser Indikatoren kann legitim sein.

Um Störsignale von echten Bedrohungen zu unterscheiden, verwenden moderne Feeds einen mehrschichtigen Ansatz:

1. Automatisiertes Scannen von Hunderten von Indikatoren in neu veröffentlichten Paketen.
2. KI- oder ML-Modelle, die Indikatorsignale kombinieren, um eine Wahrscheinlichkeitsbewertung für bösartige Absichten zu vergeben.
3. Menschliche Überprüfung für Fälle mit mittlerem Risiko und automatisierte Entfernung oder Sperrung für Erkennungen mit hoher Zuverlässigkeit.

Praktische Kontrollen, die Sie noch heute einsetzen können

Hier sind konkrete Maßnahmen, die Entwicklungs- und Sicherheitsteams ergreifen sollten, um das Risiko durch Malware in der Lieferkette zu verringern:

• Durchsetzung von bereichsbezogenen/privaten Registern für interne Pakete – Stellen Sie sicher, dass interne Paketnamen nicht mit öffentlichen Paketen verwechselt werden können, und konfigurieren Sie Paketmanager so, dass sie für interne Abhängigkeiten immer private Register bevorzugen.
• Wrap-Installationsbefehle – Fügen Sie eine Überprüfung während der Installation in CI- und Entwicklercomputern hinzu, die einen Live-Bedrohungsfeed abfragt, bevor die Installation des Pakets zugelassen wird.
• Harden Entwicklerkonten – Erfordern Sie eine Multi-Faktor-Authentifizierung für Registrierungskonten, rotieren Sie Tokens und überwachen Sie verdächtige Anmeldungen.
• Verringern Sie die Abhängigkeit von frisch veröffentlichten Paketen – Erwägen Sie Richtlinien, die ein Mindestalter für Pakete für direkte Installationen in CI vorschreiben, um die Auswirkungen von böswilligen Veröffentlichungen am selben Tag zu begrenzen.
• Integrieren Sie Bedrohungsinformationen in Ihre Pipeline – Speisen Sie Echtzeit-Listen mit bösartigen Paketen in CI/CD, Abhängigkeitsscanner und IDE-Tools ein, um riskante Pakete frühzeitig zu blockieren.
• Trainieren Sie für KI-Halluzinationen – Behandeln Sie Abhängigkeiten, die von Codegenerierungswerkzeugen vorgeschlagen werden, bis zur Überprüfung als nicht vertrauenswürdig; vermeiden Sie es, generierte Paketnamen blind in Manifeste zu kopieren.

Abschließende Gedanken

Malware in der Lieferkette ist eine aktive, sich ständig weiterentwickelnde Bedrohung. Sie nutzt sowohl menschliche Fehler (Phishing, Tippfehler) als auch Automatisierung (Verhalten der Registrierung, LLM-Halluzinationen) aus. Um sie zu bekämpfen, sind Echtzeit-Bedrohungsinformationen, Tools, die sich in normale Entwickler-Workflows integrieren lassen, und grundlegende Hygienemaßnahmen wie bereichsbezogene Registrierungen und MFA für Wartungsmitarbeiter erforderlich.

Das Erkennen und Blockieren bösartiger Pakete vor ihrer Ausführung schützt nicht nur Ihre Codebasis, sondern auch das gesamte Open-Source-Ökosystem. Sorgen Sie für eine schnelle Erkennung, integrieren Sie diese in Installationen und behandeln Sie jede neue Abhängigkeit bis zur Überprüfung als nicht vertrauenswürdig.

„Malware in der Lieferkette schlägt sofort zu – Ihre Abwehrmaßnahmen müssen noch schneller reagieren.“

‍Probieren Sie Aikido noch heute aus!