In den letzten Tagen habe ich eine Reihe von Supply-Chain-Angriffen analysiert, die einige der vertrauenswürdigsten Tools in unserem Ökosystem getroffen haben. Was zunächst wie isolierte Vorfälle aussah, entpuppt sich inzwischen als größeres systemisches Muster.
🔍 Trivy – wenn Security-Tools selbst zur Angriffsfläche werden
Trivy ist eines der meistgenutzten Open-Source-Sicherheitstools in der Cloud-Native-Welt – und wurde innerhalb eines Monats gleich zweimal kompromittiert. Die Angreifer nutzten CI/CD-Pipelines aus, stahlen Zugangsdaten und verwandelten ein vertrauenswürdiges Security-Tool in einen Verteilungsvektor für Malware. Das zeigt: Es war kein isoliertes Trivy-Problem, sondern ein grundlegendes Risiko in der Art und Weise, wie wir Open-Source-Security-Tools in unsere Build- und Deployment-Prozesse einbinden.
⚠️ LiteLLM – dasselbe Angriffsmuster, jetzt im AI-Ökosystem
Nur wenige Tage später verlagerte derselbe Angreifer seine Aktivitäten in den Bereich der AI-Infrastruktur. LiteLLM – ein zentrales Paket für viele AI-Agents und LLM-Frameworks – wurde über eine manipulierte Release-Version kompromittiert. Der Schadcode:
Startet automatisch in jedem Python-Prozess -
Sammelt API-Keys, Cloud-Zugangsdaten und Secrets -
Bewegt sich seitlich in Kubernetes-Clustern -
Installiert dauerhafte Backdoors
Besonders kritisch: Viele betroffene Umgebungen hatten LiteLLM gar nicht direkt eingebunden, sondern nur als transitive Abhängigkeit installiert.
Diese Fälle machen deutlich, dass unsere Abhängigkeit von Open Source schneller gewachsen ist als unsere Fähigkeit, Risiken darin zu erkennen und zu kontrollieren. Supply-Chain-Attacken der nächsten Generation werden nicht nur Code kompromittieren – sie werden unsere Vertrauensmodelle selbst ausnutzen.