Workstations von Entwickelnden sind zum lukrativsten Ziel bei Software-Lieferkettenangriffen geworden, und das Problem nimmt zu.
„Es gibt eine wichtige Kennzahl, die mich beunruhigt: In den letzten drei Monaten hatten wir siebenmal mehr Schwachstellen in unserer Lieferkette im Vergleich zu den drei Monaten zuvor“, sagt Gavin Williams, Engineering Manager beim Anbieter der KI-Beschaffungsplattform Omnea.
„Wir sehen im Laufe der Zeit immer mehr Probleme und Schwierigkeiten in den Registries, mit mehr Lieferkettenangriffen, aber auch mehr Problemen, die von KI-Tools erkannt werden. Es ist so einfach für Entwickelnde, ein anfälliges Paket oder etwas Kompromittiertes zu installieren.“
Die Branche hat Jahre damit verbracht, die Sicherheit nach links in die Pipeline zu verlagern. Doch die Angriffsfläche selbst hat sich noch weiter nach links verschoben als die Pipeline und auf die Maschinen selbst.
Allein im letzten Jahr sind Angreifer durch verschiedene Türen gekommen: die jüngste GitHub-Schwachstelle über eine bösartige VS Code-Erweiterung, Trivy über ein Sicherheitstool, TanStack (mini Shai-Hulud) über einen Paketmanager, TeamPCP-Angriffe über bösartige Pakete, aber sie alle haben einen Schlüsselfaktor gemeinsam. Sie zielen auf das Gerät der Entwickelnden ab. Und es funktioniert.
Aber warum?
Ich stelle es mir so vor: Die meisten Geschäftsgebäude haben ihre Vordertür mit Schlössern, Kameras und Ähnlichem gesichert. Aber es gibt auch einen Personaleingang auf der Rückseite mit einer offen stehenden Brandschutztür, weil den ganzen Tag über Leute mit Lieferungen kommen und gehen. Dieser Personaleingang führt direkt zum Büro mit den Schlüsseln zu jedem Raum, was effektiv die Workstation der Entwickelnden ist.
Organisationen und ihre Sicherheitsteams haben dies bisher nicht als Sicherheitsrisiko betrachtet, weil „es ja nur für sie ist“. Es ist eine Art blinder Glaube, dass sich niemand darum kümmern wird, weil es nicht für sie ist.
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) ist, es ist sinnvoll, dorthin zu gehen, wo der Widerstand am geringsten ist.
Die Lücke zwischen dem, was EDR sieht, und dem, was Entwickelnde tatsächlich installieren
Einer der Hauptgründe für Lieferkettenangriffe ist, laut James Berthoty, Gründer und Analyst bei Latio, dass Endpunkte von Entwickelnden weitgehend unüberwacht bleiben, da traditionelle Erkennungs- und Verwaltungstools für ihre Anwendungsfälle nicht gut funktionieren.
„EDR-Tools sind nicht granular, sie konzentrieren sich hauptsächlich auf die installierten Apps oder Programme und nicht auf die inneren Pakete dieser zugelassenen Anwendung“, sagt Walid Mahmoud, DevSecOps Lead im öffentlichen Sektor des Vereinigten Königreichs.
EDR überwacht auf Anwendungsebene nach bösartiger Aktivität. Aber Organisationen können nicht sehen, was in den Tools passiert, die Entwickelnde täglich verwenden, wie die npm-Pakete, die IDE-Erweiterungen, die Chrome-Plugins, die Cursor-Skills.
Das ist wichtig, denn das Problem beginnt, bevor auch nur eine einzige Codezeile geschrieben wird.
„Es geht nicht darum, dass Leute unsicheren Code in die Produktion deployen. Es geht darum, dass schon bei der Installation GitHub-Zugangsdaten offengelegt werden“, sagt Gavin von Omnea.
Zum Beispiel kann ein bösartiges Paket ein Post-Install-Skript ausführen und Zugangsdaten exfiltrieren, sobald ein Entwickelnder es installiert.
Und natürlich wäre es ein Versäumnis, nicht zu erwähnen, wie trivial einfach es dank LLMs wird, Malware zu erstellen. Steeven George, Head of Product Security bei Raisin, sagt, dass dies ein Bereich war, der einen „blinden Fleck“ für seine Organisation schuf, und er ist nicht der Einzige.
Walid aus dem öffentlichen Sektor des Vereinigten Königreichs erklärt, was die Einführung von KI bewirkt: „Viele Leute leben jetzt im Terminal und installieren viele Markdown-Dateien und andere Dinge. Ohne verifizierte Prozesse hindert sie natürlich nichts daran, Dinge herunterzuladen, die sie auf Reddit oder X gesehen haben. Diese könnten Teil einer Malware-Kampagne sein, um Leute zum Herunterladen zu bewegen. Und dann – der Rest ist Geschichte.“
Ein Teil des Problems ist, dass kein einzelnes Team die Schnittstelle verantwortet, an der Entwickelnden-Maschinen angesiedelt sind und wo AppSec, Endpunktsicherheit, Identität und Lieferkettenrisiken zusammenlaufen. Daher war es einfacher, Tools wie EDR und MDM zu nutzen, um diese Lücke zu füllen, ohne Organisationen wirklich vor diesen wachsenden Bedrohungen zu schützen. Es wird jedoch immer deutlicher, dass dies nicht länger tragbar ist. Der Nachteil ist, Ziel eines erheblichen Lieferkettenangriffs zu werden (Das ist ein erheblicher Nachteil).
Wie Teams Entwickelnden-Maschinen vor Lieferkettenangriffen schützen
Chris Holman, DevSecOps Engineer Teamleiter beim Cybersicherheitsunternehmen Glasswall, hat Aikido Safe Chain im gesamten Unternehmen ausgerollt.
“Jede Produktions-Pipeline, die unterstützte Pakete berührt, wird jetzt mit Safe Chain gescannt, um sicherzustellen, dass wir nichts Manipuliertes installieren.”
Walid hat dasselbe in der gesamten britischen Behörde des öffentlichen Sektors getan.
“Es wurde ein Stage Gate hinzugefügt, den wir normalerweise in unserem Softwareentwicklungs-Lebenszyklus haben, aber dieser Stage Gate ist jetzt lokal. So haben wir etwas mehr Vertrauen, dass Entwickelnde eine Art Leitplanke auf ihrer lokalen Maschine haben, die sie hinterfragt, bevor sie etwas installieren.”
Pakete sind jedoch nur ein Einstiegspunkt; Gavins Team nutzte bereits Safe Chain, als sie, wie er sagte, erkannten, dass sie eine breitere Sichtbarkeit über das gesamte Entwickelnden-Gerät hinweg benötigten.
“Wir haben Safe Chain bisher genutzt, aber eine umfassendere Möglichkeit, alle Geräte zu verwalten und wirklich zu überprüfen, dass Dinge nicht unsicher installiert werden, wird ein echter Game Changer sein”, sagte Gavin.
Das führte mehrere dieser Teams zu Aikido’s Device Protection, das dasselbe Prinzip über Paket-Registries hinaus auf IDE-Erweiterungen, Browser-Plugins und KI-Tools ausdehnt.
Walid beschreibt es als eine “aufgerüstete Version von Safe Chain”. Er sagt: “Es liefert uns die Telemetriedaten, um zu wissen, was Entwickelnde nutzen oder was sie zu installieren versucht haben – was uns mehr Kontext darüber gibt, wer anfällig für einen Angriff ist.”
Kristinas Team bei Cognism plant, es aus ähnlichen Gründen einzusetzen. “Keine anderen Tools bieten derzeit diese Art von Abdeckung. EDR-Tools zeigen keine installierten Pakete auf Entwickelnden-Maschinen an, und Schwachstellen in Chrome-Erweiterungen werden von anderen Anbietern nicht abgedeckt. Wir werden diese Lücke definitiv schließen.”
Steeven hat es bereits getestet. “Ich freue mich sehr über die vollständige Übersicht über Browser-Erweiterungen, Cursor-Erweiterungen und alle Paket-Registries. Es liefert uns ein umfassendes Bedrohungsmodell für alle unsere Entwickelnden-Maschinen.”
Jedes Team, mit dem wir sprachen, fand dieselbe Lücke
Das Muster in diesen Gesprächen war konsistent: Sicherheits- und Engineering-Führungskräfte in verschiedenen Unternehmen und Branchen identifizierten alle unabhängig voneinander dieselbe Lücke. Entwickelnden-Maschinen fallen durch die Maschen bestehender Tools, und Angreifer haben das erkannt.
Die Teams, die sich bereits damit befassten, begannen mit Paket-Level-Kontrollen und erweitern diese nun auf eine vollständige Geräte-Sichtbarkeit. Diejenigen, die noch nicht begonnen haben, verwenden wahrscheinlich dieselbe EDR- und MDM-Einrichtung, die jeden in diesem Artikel erwähnten Angriff übersehen hat.
Erfahren Sie hier, wie Device Protection funktioniert, oder probieren Sie es hier aus.
