Sie haben LiteLLM gepatcht – kennen Sie aber den gesamten KI-Risikoradius?

Für kurze Zeit war ein weit verbreitetes Open-Source-Paket im KI-Ökosystem mit Malware zum Diebstahl von Zugangsdaten kompromittiert.

LiteLLM, ein Modell-Gateway, über das Anfragen an mehr als 100 LLM-Anbieter weitergeleitet werden, wurde täglich millionenfach heruntergeladen. In diesem kurzen Zeitraum wurden die schädlichen Versionen wahrscheinlich Zehntausende Male heruntergeladen, bevor der Angriff entdeckt wurde.

Theoretisch hätte das beruhigend sein sollen: Das Projekt verfügte über Compliance-Zertifizierungen, Sicherheits-Tools waren im Einsatz und das Problem wurde schnell entdeckt und behoben. Doch genau darin liegt das Problem.

Denn bei diesem Vorfall ging es nicht nur um eine kompromittierte Abhängigkeit. Er führte uns vor Augen, wie moderne KI-Systeme tatsächlich versagen: nicht an der Oberfläche, sondern über Ebenen hinweg, die wir nicht vollständig überblicken.

Ein erstes Anzeichen für die Auswirkungen zeichnet sich bereits ab. Das KI-Recruiting-Startup Mercor bestätigte, eines von „Tausenden“ nachgelagerten Opfern des LiteLLM-Supply-Chain-Angriffs zu sein. In diesem Fall blieb es nicht bei einem kompromittierten Paket: Berichten zufolge kam es zu einem umfangreichen Datenabfluss, darunter auch Quellcode, nachdem gestohlene Zugangsdaten für den Zugriff auf interne Systeme verwendet worden waren.

Genau diesen Punkt übersehen die meisten Teams. Das Risiko liegt nicht in der Abhängigkeit selbst, sondern darin, worauf sie zur Laufzeit zugreifen kann. Sobald etwas wie LiteLLM im Ausführungspfad zwischen Ihrer Anwendung und den Modellanbietern sitzt, wird es zum Zugang zu allem dahinter: APIs, Tools, Agenten-Workflows und sensiblen Daten.

Mercor und andere wurden nicht einfach deshalb kompromittiert, weil sie „LiteLLM nutzten“. Sie wurden kompromittiert, weil LiteLLM mit bestimmten Systemen verbunden war.

Die Malware beim ursprünglichen LiteLLM-Angriff war vergleichsweise wenig ausgefeilt. Sie verursachte auffällige Störungen, brachte Rechner zum Absturz und wurde entdeckt. Eine subtilere Variante, die unbemerkt Zugangsdaten bei Modellanbietern abgreift und sich über APIs und Agenten-Workflows verbreitet, hätte wochenlang unentdeckt bleiben können.

Und wäre das geschehen, hätten die meisten Teams nicht gewusst, was tatsächlich gefährdet war. Sie hätten gewusst, dass sie LiteLLM verwendeten.

Sie hätten nicht gewusst:

• Welche Modelle darüber weitergeleitet wurden

• Welche Anbieter beteiligt waren

• Auf welche Tools und Systeme diese Modelle zugreifen konnten

• Wie sich dieses Risiko in ihren Anwendungen ausbreitete

Genau hier liegt die Lücke. Deshalb sind Vorfälle wie dieser nicht mehr nur Supply-Chain-Probleme, sondern letztlich eine Frage der Transparenz bei KI-Systemen.

Als der LiteLLM-Angriff bekannt wurde, taten die meisten Teams genau das, was man erwarten würde. Sie überprüften ihre Abhängigkeiten, ermittelten die anfälligen Versionen und handelten schnell, um sie zu patchen oder auf eine sichere Version festzulegen. Aus Sicht der klassischen Anwendungssicherheit ist das gut gemacht.

Doch das wirft eine interessantere Frage auf, die sich die meisten Teams nicht stellen: Was haben Sie eigentlich behoben?

Es geht darum, nicht nur herauszufinden, wo LiteLLM verwendet wurde, sondern auch, was es in Ihrem System tat, womit es verbunden war und welches Risiko dadurch über das Paket selbst hinaus entstand. Denn bei KI-Anwendungen wird es genau dort kompliziert.

Wo die herkömmliche Transparenz an ihre Grenzen stößt

LiteLLM ist nicht einfach eine weitere Bibliothek, die unauffällig in einer Codebasis liegt. Sie befindet sich direkt im Ausführungspfad zwischen Ihrer Anwendung und den Modellen, auf die sie angewiesen ist. Sie leitet Anfragen weiter, abstrahiert Anbieter und prägt letztlich das Verhalten Ihres Systems zur Laufzeit.

Das bedeutet: Wird LiteLLM kompromittiert, beschränken sich die Auswirkungen nicht auf die Repositories, in denen das Paket enthalten ist. Sie reichen bis zu den Modellen, die darüber aufgerufen werden, den beteiligten Anbietern, den Tools, auf die diese Modelle zugreifen können, und den Agenten-Workflows, die davon abhängen.

Hier verlieren die meisten Teams den Überblick. Eine einzelne Codezeile, in der ein Modell angegeben wird, mag unbedeutend erscheinen. Doch sie enthält eine Reihe von Entscheidungen zu Anbietern, Funktionen und Zugriffsrechten, die in keinem Abhängigkeitsgraphen erfasst werden.

Über Repositories, Teams und sich weiterentwickelnde Agenten-Workflows hinweg betrachtet, ergibt sich daraus nicht einfach nur ein Abhängigkeitsproblem. Es entsteht ein System, das schwer vollständig zu überblicken und zu verstehen ist.

Die Lücke, die Evo AI-SPM schließen soll

Anstatt sich ausschließlich auf vorhandene Abhängigkeiten zu konzentrieren, legt Evo den Fokus darauf, wie KI genutzt wird. Im Fall von LiteLLM bedeutet das, das Tool als Modell-Gateway zu identifizieren, zu erfassen, welche Anbieter und Modelle darüber angesteuert werden, die Tools und APIs zu entdecken, mit denen diese Modelle interagieren, und all das mit den Agenten-Workflows zu verknüpfen, die das Systemverhalten bestimmen.

Das Ergebnis ist eine AI-BOM: eine aktuelle Übersicht des KI-Systems selbst – nicht nur der Komponenten, aus denen es besteht.

Warum der Kontext alles verändert

Dieser zusätzliche Kontext verändert grundlegend, wie Teams auf Vorfälle reagieren. Wenn Sie nur wissen, dass LiteLLM kompromittiert wurde, liegt der nächste Schritt auf der Hand: das Problem beheben. Doch sobald Sie verstehen, wie es genutzt wird, wird die Reaktion differenzierter.

Sie können zunächst fragen, ob Datenverkehr an nicht genehmigte Modellanbieter weitergeleitet wird, welche Agenten auf diesen Pfad angewiesen sind, welche externen Systeme dadurch offengelegt werden und ob diese Interaktionen überhaupt durch Richtlinien geregelt sind. Das ist der Unterschied zwischen der Reaktion auf eine Schwachstelle und dem Verständnis Ihrer tatsächlichen Angriffsfläche.

So werden KI-Anwendungen bereits entwickelt

Das spiegelt wider, wie viele KI-gestützte Anwendungen bereits entwickelt werden. Entwicklerinnen und Entwickler nutzen vielleicht ein Framework, um einen Agenten zu orchestrieren, verlassen sich auf LiteLLM, um den Modellzugriff zu abstrahieren, und verbinden den Agenten mit externen Tools oder APIs, damit er Aufgaben erledigen kann. Aus herkömmlicher Sicht erscheint das als anfällige Abhängigkeit. Aus Systemsicht ist es eine Kette von Entscheidungen, Integrationen und Verhaltensweisen, die weit über das Paket selbst hinausgeht.

Die KI, von der Sie gar nicht wissen, dass Sie sie haben

Oft sind Teams überrascht, wie viel KI bereits in ihren Umgebungen steckt. Viele glauben, sie stünden noch ganz am Anfang ihrer KI-Einführung. Dann entdecken sie in ihren Codebasen eine verstreute Nutzung von Modell-Gateways, Orchestrierungs-Frameworks und neuen Agentenmuster.

Nichts davon ist zentralisiert, vieles wird nicht gesteuert – und dennoch ist all das bereits Teil von Produktionssystemen. Vorfälle wie der LiteLLM-Angriff schaffen diese Komplexität nicht, sondern machen sie sichtbar.

Sie brauchen weiterhin SCA – aber nicht nur SCA

Das ist kein Versagen der Software Composition Analysis (SCA). Tools wie Snyk Open Source kennzeichnen kompromittierte LiteLLM-Versionen, zeigen, wo diese Versionen in Repositories vorkommen – auch als transitive Abhängigkeiten –, benachrichtigen Teams schnell und bieten klare Hinweise zur Behebung.

Dieses Signal ist grundlegend. Ohne es wüssten Teams nicht einmal, dass ein Problem vorliegt. Doch SCA ist darauf ausgelegt, eine ganz bestimmte Frage zu beantworten: „Ist diese Abhängigkeit anfällig?“ Die Herausforderung besteht darin, dass moderne KI-Systeme nicht bei Abhängigkeiten enden.

Auf Vorfälle wie diesen reagieren viele mit den Worten: „SCA hat das doch bereits erkannt.“ Das stimmt, setzt aber voraus, dass die Abhängigkeit das System ist. Tatsächlich ist sie nur der Einstiegspunkt. Das System umfasst alles, was diese Abhängigkeit ermöglicht: Modellzugriff, Tool-Ausführung, Agenten-Orchestrierung und dynamische Entscheidungsfindung. Wenn Sie diese Ebene nicht sehen können, verstehen Sie nicht vollständig, wo Ihr Risiko liegt.

Der LiteLLM-Angriff ist nur ein Beispiel, macht den notwendigen Wandel aber deutlich: Wenn Sie nur auf Abhängigkeiten schauen, sehen Sie das System nicht. SCA zeigt Ihnen, dass etwas nicht stimmt. Evo hilft Ihnen zu verstehen, was das im Kontext Ihres KI-Systems bedeutet, und gibt Ihnen die Möglichkeit, es zu kontrollieren.

So nutzen Sie Evo AI-SPM

Mit Evo AI-SPM können Sie Ihre eigene Umgebung schnell und einfach überblicken. In wenigen Minuten können Sie:

• Ermitteln, in welchen Ihrer Repositories LiteLLM und ähnliche Modell-Gateways vorkommen

• Sehen, welche Modellanbieter und Modelle darüber angesteuert werden

• Verbundene Tools, APIs, Agenten und Workflows entdecken

• „Shadow AI“ aufdecken, die herkömmliche Sicherheitstools nicht erkennen

• Richtlinien festlegen, um künftig zu kontrollieren, was zulässig ist

Die meisten Teams sind vom ersten Scan überrascht. Denn die Realität ist: Wenn Sie mit KI entwickeln, haben Sie bereits eine KI-Supply-Chain. Möglicherweise können Sie sie nur noch nicht sehen.

Snyk Open Source hilft Ihnen, Schwachstellen zu finden.

Evo AI-SPM zeigt Ihnen das System und hilft Ihnen, es abzusichern.

Fangen Sie dort an.