Entwickelnde sind zum Ziel mit dem höchsten ROI bei Lieferkettenangriffe Software-Lieferkette geworden, und das Problem verschärft sich zunehmend.
„Es gibt eine Kennzahl, die mir besonders Sorgen bereitet: In den letzten drei Monaten hatten wir siebenmal mehr Schwachstellen in unserer Lieferkette als in den drei Monaten zuvor“, sagt Gavin Williams, Engineering Manager beim Anbieter der KI-Beschaffungsplattform Omnea.
„Mit der Zeit tauchen in den verschiedenen Repositories immer mehr Probleme und Schwachstellen auf – es gibt Lieferkettenangriffe mehr Lieferkettenangriffe auch mehr Probleme, die von KI-Tools aufgedeckt werden. Für Entwickler ist es so einfach, ein anfälliges Paket oder etwas zu installieren, das kompromittiert wurde.“
Die Branche hat jahrelang daran gearbeitet, die Sicherheit in der Entwicklungspipeline nach vorne zu verlagern. Doch die Angriffsfläche selbst hat sich noch weiter nach vorne verlagert – über die Pipeline hinaus direkt auf die Maschinen selbst.
Allein im vergangenen Jahr haben Angreifer auf unterschiedlichen Wegen Zugang erlangt: der jüngste Angriff auf GitHub über eine bösartige VS-Code-Erweiterung, Trivy ein Sicherheitstool, TanStack (Mini-Shai-Hulud) über einen Paketmanager und TeamPCP-Angriffe über bösartige Pakete – doch alle haben eines gemeinsam: Sie zielen auf die Geräte der Entwickler ab. Und das funktioniert.
Aber warum?
Ich stelle mir das gerne so vor: Die meisten Geschäftsgebäude sind an der Vordertür mit Schlössern, Kameras und Ähnlichem gesichert. Aber es gibt auch einen Personaleingang auf der Rückseite, dessen Brandschutztür offen steht, weil dort den ganzen Tag über Leute mit Lieferungen ein- und ausgehen. Dieser Personaleingang führt direkt zu dem Büro, in dem die Schlüssel für alle Räume aufbewahrt werden – praktisch der Arbeitsplatz des Entwicklers.
Unternehmen und ihre Sicherheitsteams haben dies bislang nicht als Sicherheitsrisiko betrachtet, weil „es ja nur sie betrifft“. Es ist eine Art blinder Glaube, dass sich niemand darum kümmern wird, weil es nicht sie betrifft.
Aber wenn man ein Angreifer ist, spielt es buchstäblich keine Rolle, für wen die Tür (oder in diesem Fall das Gerät) bestimmt ist – es ist sinnvoll, dorthin zu gehen, wo der Widerstand am geringsten ist.
Die Diskrepanz zwischen dem, was EDR erkennt, und dem, was Entwickler tatsächlich installieren
Einer der Hauptgründe für Lieferkettenangriffe ist laut James Berthoty, Gründer und Analyst bei Latio, dass die Endgeräte von Entwicklern weitgehend unüberwacht bleiben, da herkömmliche Erkennungs- und Verwaltungstools für ihre Anwendungsfälle nicht gut geeignet sind.
„EDR-Tools sind nicht detailliert genug; sie konzentrieren sich in erster Linie auf die installierten Apps oder Programme und nicht auf die internen Komponenten der jeweiligen zugelassenen Anwendung“, sagt Walid Mahmoud, DevSecOps im öffentlichen Sektor des Vereinigten Königreichs.
EDR überwacht auf Anwendungsebene auf böswillige Aktivitäten. Unternehmen haben jedoch keinen Einblick in die Vorgänge innerhalb der Tools, die Entwickler täglich nutzen, wie beispielsweise npm-Pakete, IDE-Erweiterungen, Chrome-Plugins und Cursor-Skills.
Das ist wichtig, denn das Problem beginnt schon, bevor auch nur eine einzige Zeile Code geschrieben wurde.
„Es geht nicht darum, dass Leute unsicheren Code in der Produktion einsetzen. Es geht darum, dass bereits bei der Installation ihre GitHub-Zugangsdaten offengelegt werden“, sagt Gavin von Omnea.
So kann beispielsweise ein schädliches Paket ein Skript nach der Installation ausführen und Anmeldedaten abgreifen, sobald ein Entwickler es installiert.
Und natürlich wäre es fahrlässig, nicht zu erwähnen, wie kinderleicht es dank LLMs mittlerweile ist, Malware zu erstellen. Steeven George, Leiter der Produktsicherheit bei Raisin, sagt, dass dies ein Bereich sei, der für sein Unternehmen einen „blinden Fleck“ darstelle – und er ist nicht der Einzige.
Walid, der im öffentlichen Dienst des Vereinigten Königreichs tätig ist, erläutert die Auswirkungen der Einführung von KI: „Viele Menschen arbeiten mittlerweile über die Befehlszeile und installieren dort jede Menge Markdown-Dateien und andere Dinge. Da es jedoch natürlich keine überprüften Prozesse gibt, hindert sie nichts daran, Dinge herunterzuladen, die sie auf Reddit oder X gesehen haben. Diese könnten Teil einer Malware-Kampagne sein, die darauf abzielt, Nutzer zum Herunterladen zu verleiten. Und dann – der Rest ist Geschichte.“
Ein Teil des Problems besteht darin, dass kein einzelnes Team die Verantwortung für den Schnittbereich trägt, in dem sich die Entwicklerrechner befinden – dort, wo AppSec, Endpunktsicherheit, Identitätsmanagement und Risiken in der Lieferkette aufeinandertreffen. Daher war es bisher einfacher, Tools wie EDR und MDM einzusetzen, um die Lücke zu füllen, ohne Unternehmen wirklich vor diesen wachsenden Bedrohungen zu schützen. Doch es wird immer deutlicher, dass dies nicht mehr tragbar ist. Der Nachteil besteht darin, Opfer eines schwerwiegenden Angriffs auf die Lieferkette zu werden (das ist ein ziemlicher Nachteil).
Wie Teams die Rechner ihrer Entwickler vor Lieferkettenangriffe schützen
Chris Holman, Teamleiter DevSecOps beim Cybersicherheitsunternehmen Glasswall, hat Aikido Chain unternehmensweit eingeführt.
„Jede Produktionspipeline, die mit unterstützten Paketen arbeitet, wird nun mit Safe Chain gescannt, um sicherzustellen, dass wir keine manipulierten Dateien installieren.“
Walid hat dasselbe im gesamten öffentlichen Dienst des Vereinigten Königreichs getan.
„Es wurde eine Kontrollinstanz hinzugefügt, wie wir sie normalerweise in unserem Softwareentwicklungszyklus haben, aber diese Kontrollinstanz ist nun lokal. So haben wir etwas mehr Vertrauen, dass die Entwickler auf ihrem lokalen Rechner eine Art Sicherheitsbarriere haben, die sie zur Sicherheit abfragt, bevor sie etwas installieren.“
Doch Pakete sind nur ein Ansatzpunkt; Gavins Team nutzte Safe Chain bereits, als ihnen klar wurde, dass sie einen umfassenderen Überblick über das gesamte Entwicklergerät benötigten.
„Wir haben bisher Safe Chain genutzt, aber eine umfassendere Möglichkeit, alle Geräte zu verwalten und wirklich sicherzustellen, dass keine unsicheren Anwendungen installiert werden, wird eine echte Wende bedeuten“, sagte Gavin.
Das hat mehrere dieser Teams dazu veranlasst, sich mit „Device Protection“Aikido zu befassen, das dasselbe Prinzip über Paketregister hinaus auf IDE-Erweiterungen, Browser-Plugins und KI-Tools ausweitet.
Walid beschreibt es als „erweiterte Version von Safe Chain“. Er sagt: „Dadurch erhalten wir die notwendigen Daten, um zu erkennen, welche Tools Entwickler nutzen oder was sie zu installieren versucht haben – so bekommen wir einen besseren Überblick darüber, wer für einen Angriff anfällig ist.“
Kristinas Team bei Cognism plant aus ähnlichen Gründen die Einführung dieser Lösung. „Derzeit bietet kein anderes Tool eine derart umfassende Abdeckung. EDR-Tools zeigen keine auf Entwicklerrechnern installierten Pakete an, und Schwachstellen in Chrome-Erweiterungen werden von anderen Anbietern nicht abgedeckt. Diese Lücke werden wir definitiv schließen.“
Steeven hat es bereits getestet. „Ich bin wirklich froh, dass ich nun einen vollständigen Überblick über Browser-Erweiterungen, Cursor-Erweiterungen und alle Paket-Registerstellen habe. Das verschafft uns ein umfassendes Bedrohungsbild für alle unsere Entwickler-Rechner.“
Jedes Team, mit dem wir gesprochen haben, stellte dieselbe Lücke fest
Das Muster, das sich in diesen Gesprächen abzeichnete, war einheitlich: Führungskräfte aus den Bereichen Sicherheit und Technik in verschiedenen Unternehmen und Branchen stellten unabhängig voneinander dieselbe Lücke fest. Entwickelnde fallen durch die Maschen der bestehenden Tools, und Angreifer haben das erkannt.
Die Teams, die sich bereits damit befassen, haben mit Kontrollen auf Paketebene begonnen und erweitern diese nun auf eine vollständige Gerätetransparenz. Diejenigen, die noch nicht damit begonnen haben, nutzen wahrscheinlich dieselbe EDR- und MDM-Konfiguration, die jeden in diesem Artikel erwähnten Angriff übersehen hat.
Erfahren Sie hier, wie Device Protection funktioniert, oder probieren Sie es hier aus.
