Trivy, KICS, LiteLLM: Eine Warnung zur Lieferkette hinsichtlich transitiver Abhängigkeiten

Wie sich eine Sicherheitslücke in einem bewährten Sicherheitstool auf Checkmarx KICS und LiteLLM auswirkte und das tatsächliche Risiko transitiver Abhängigkeiten offenlegte.

Die letzten Tage haben uns eindringlich vor Augen geführt, dass Angriffe auf die Lieferkette nicht schon mit dem ersten kompromittierten Projekt enden. Was mit einer bösartigen Trivy-Version begann, scheint sich zu einem separaten, aber ähnlichen Angriff ausgeweitet zu haben, der Checkmarx KICS GitHub Actions und anschließend LiteLLM betraf. Zusammengenommen zeigen diese Ereignisse, warum Teams transitiven Abhängigkeiten mehr Aufmerksamkeit schenken müssen und nicht nur den Paketen, die sie bewusst installieren. Öffentliche Berichte deuten zudem darauf hin, dass dies Teil einer umfassenderen Kampagne ist, die TeamPCP zugeschrieben wird, einem Bedrohungsakteur, der auf Telegram präsent ist.

Die bösartige Trivy-Version v0.69.4 vom 19. März 2026:

Der erste größere Vorfall betraf Trivy. Am 19. März 2026 veröffentlichten Angreifer die bösartige Version v0.69.4 und manipulierten die zugehörigen GitHub-Vorgänge. Laut öffentlichen Berichten injizierten sie einen „Info-Stealer“ in CI/CD-Workflows, sammelten sensible Daten wie SSH-Schlüssel, Tokens und Umgebungsvariablen und exfiltrierten diese, während der Workflow normal weiterlief.

Dies erhöhte die Gefahr erheblich, da Trivy nun ein vertrauenswürdiges Sicherheitstool war, das an einem Ort eingesetzt wurde, an dem häufig hochwertige Anmeldedaten vorhanden sind.

Das ist von Bedeutung, da Trivy häufig in Build- und Release-Pipelines eingesetzt wird. Wenn Angreifer ein Tool in dieser Position kompromittieren, beschränkt sich der Schaden nicht auf das Tool selbst. Die eigentliche Sorge betrifft die Daten und Ressourcen, auf die sie während der Ausführung Zugriff hatten.

Der Checkmarx-KICS-Hack am 23. März:

Am 23. März machten Sicherheitsforscher einen separaten, aber ähnlichen Angriff bekannt: Angreifer zielten auf Checkmarx-KICS-GitHub-Actions, nutzten ähnliche Methoden und setzten dabei eine andere Infrastruktur ein. Ob alle Details identisch waren, ist weniger wichtig als das übergeordnete Muster. Angreifer manipulierten vertrauenswürdige Automatisierungskomponenten, um geheime Daten aus CI/CD-Umgebungen abzugreifen. Allein dies sollte jedes Unternehmen beunruhigen, das in hohem Maße auf GitHub-Actions und andere Pipeline-Tools setzt.

Schädliche Veröffentlichungen bei LiteLLM:

Und dann kam LiteLLM. Am 24. März gab LiteLLM bekannt, dass die schädlichen Versionen 1.82.7 und 1.82.8 auf PyPI veröffentlicht worden waren. Das gemeldete Verhalten umfasste erneut die Suche nach SSH-Schlüsseln, Cloud-Anmeldedaten, Tokens und Umgebungsvariablen sowie deren anschließende Exfiltration. Was den Vorfall bei LiteLLM besonders bedeutsam machte, war der wahrscheinliche Zusammenhang mit dem früheren Trivy-Hack. Öffentliche Berichte verknüpfen die Kompromittierung von LiteLLM mit Anmeldedaten, die Angreifer vermutlich durch einen Trivy-Scanner auf LiteLLMs CI/CD-Pipeline offengelegt haben. Nun handelt es sich nicht mehr nur um eine Geschichte über eine einzige fehlerhafte Veröffentlichung eines Pakets. Es wurde zu einer Geschichte über eine Kompromittierung, die sich über die Software-Lieferkette ausbreitet.

Das Problem der transitiven Abhängigkeiten:

LiteLLM macht das Problem der transitiven Abhängigkeiten zudem deutlich sichtbarer. Nicht jeder betroffene Nutzer hat diese schädlichen LiteLLM-Versionen unbedingt direkt installiert. In manchen Umgebungen wurde LiteLLM möglicherweise indirekt über KI-Tools, Orchestrierungs-Frameworks oder andere vorgelagerte Abhängigkeiten bezogen. Beispielsweise zieht das beliebte Python-Projekt „dspy“, das für KI-Workflows eingesetzt wird und über 33.000 Sterne auf GitHub hat, „LiteLLM“ als transitive Abhängigkeit ein. Daher kann ein „pip install dspy“ das bösartige litellm-Paket einbinden, obwohl der Entwickler eigentlich nicht die Absicht hatte, litellm zu installieren.  Mit anderen Worten: Das Risiko geht möglicherweise nicht von einem Paket aus, das ein Entwickler explizit ausgewählt hat. Es könnte entstanden sein, weil etwas anderes im Abhängigkeitsgraphen darauf verwiesen hat.

Genau hier haben viele Teams noch eine Schwachstelle. Sie haben vielleicht einen guten Überblick über die in Manifesten deklarierten direkten Abhängigkeiten, verstehen aber viel weniger, was indirekt in das System gelangt. Angreifer erzielen einen Volltreffer, wenn die Schadsoftware in der Umgebung landet und mit Zugriff auf Geheimnisse ausgeführt wird.

Die Notwendigkeit, die Software-Kompositionsanalyse weiterzuentwickeln:

Die letzten Wochen haben uns gezeigt, warum die Software-Kompositionsanalyse nicht bei einer einfachen Liste von Paketen Halt machen darf. Die bessere Frage lautet nicht nur: „Verwenden wir dieses Paket?“, sondern auch: „Wie gelangte es hierher, welche Abhängigkeiten brachte es mit, und wo lief es?“ Teams müssen Abhängigkeitsbeziehungen, den Kontext der Build-Pipeline und die Versionsauflösungspfade verstehen – anstatt nur ein Inventar zu erstellen.

Die allgemeine Erkenntnis ist hier klar: Diese Vorfälle fügen sich in ein breiteres Muster ein, das bereits bei früheren Angriffen auf die Software-Lieferkette zu beobachten war. TeamPCP, der Microsoft als verantwortliche Gruppe identifiziert, kompromittierte kürzlich Trivy, Checkmarx KICS und LiteLLM und zeigte damit dasselbe zugrunde liegende Problem, das bereits in früheren Fällen auftrat: In Shai-Hulud verbreiteten Angreifer kompromittierte npm-Pakete durch Missbrauch von Maintainer-Konten und vorinstallierte Ausführung. In Glassworm versteckten sie bösartigen Code in vertrauenswürdigen Entwicklertools. Im älteren Event-Stream-Vorfall zog ein weit verbreitetes Paket die bösartige flatmap-stream-Abhängigkeit ein und übertrug das Risiko auf ahnungslose Nutzer.

Genau das zeigen diese Vorfälle. Das Problem sind nicht nur bösartige Pakete. Es sind bösartige Pakete, die sich über vertrauenswürdige Beziehungen verbreiten.