Die neue Ära des Software-Lieferkettenrisiko

Moderne Unternehmen sind heute Software-Unternehmen, und das Software-Lieferkettenrisiko ist inzwischen ein Geschäftsrisiko, nicht nur ein Problem für Entwickler. Ob Sie industrielle Komponenten herstellen, Finanztransaktionen verarbeiten, Logistiknetzwerke betreiben oder Online-Shops verwalten – Ihr Unternehmen ist wahrscheinlich von ERP-Systemen, Kundenportalen, Zahlungsintegrationen, Cloud-Workloads, APIs, Automatisierungsskripten und weiteren Code-Ebenen abhängig, die aus Open-Source-Komponenten, Drittanbieter-Bibliotheken, SaaS-Tools und CI/CD-Workflows zusammengesetzt sind.

In der Praxis schreiben nur sehr wenige Organisationen den Großteil dessen, was sie betreiben, selbst. Sie setzen es zusammen; der moderne Software-Stack wird ebenso geerbt wie gebaut. Genau deshalb verdient das Software-Lieferkettenrisiko mehr Aufmerksamkeit. Wenn Menschen von einem „Software-Lieferkettenangriff“ hören, denken sie oft an etwas wie Log4Shell oder MOVEit: eine weit verbreitete Komponente mit einer Schwachstelle, die Angreifer ausnutzen. Doch drei aktuelle Vorfälle rund um das Axios-npm-Ökosystem, das LiteLLM-AI-Proxy-Paket und den Trivy-Sicherheitsscanner deuten auf eine interessante Weiterentwicklung der Taktiken hin, die sich genauer anzusehen lohnt.

Drei Vorfälle, die das Software-Lieferkettenrisiko neu definieren

Drei aktuelle Vorfälle in der Software-Lieferkette zeigen eine Verlagerung hin zur Kompromittierung der Mechanismen, die Software selbst veröffentlichen, automatisieren und validieren. Im Folgenden sehen wir uns an, was in jedem Fall passiert ist.

1. Axios

Axios ist eine der am weitesten verbreiteten JavaScript-Bibliotheken für HTTP-Anfragen. Praktisch gesehen steckt sie in:

• Webanwendungen, die mit Backend-APIs kommunizieren
• SaaS-Plattformen, die Drittanbieterdienste integrieren
• Internen Unternehmens-Dashboards, die Daten aus Microservices abrufen
• Zahlungs-, Logistik-, CRM- und Analysesystemen, die ausgehende API-Anfragen senden

Wenn Ihr Unternehmen moderne Webanwendungen betreibt, die auf Node.js oder Frontend-Frameworks wie React oder Vue basieren, ist Axios oft Teil des Abhängigkeitsbaums – manchmal direkt, oft indirekt. In diesem Fall, über den im März 2026 berichtet wurde, kompromittierten Angreifer ein Maintainer-Konto (ein autorisiertes Entwicklerkonto mit der Berechtigung, offizielle Updates für das Paket zu veröffentlichen) und veröffentlichten schädliche Versionen von Axios auf npm.

Das schädliche Update führte eine Phantom-Abhängigkeit ein, die einen Remote-Access-Trojaner (RAT) enthielt. Diese Abhängigkeit war im offiziellen GitHub-Repository nicht sichtbar. Stattdessen veröffentlichte der Angreifer manuell manipulierte Versionen mithilfe eines gestohlenen npm-Tokens.

Entscheidend ist, dass dadurch die OIDC-Trusted-Publisher-Schutzmechanismen von GitHub Actions umgangen wurden. Weil das Release nicht aus dem offiziellen automatisierten Workflow stammte, wurden Herkunftssignale effektiv ausgehebelt.

Für nachgelagerte Unternehmen sah nichts ungewöhnlich aus. Entwickler, die die neueste Version über die normale Abhängigkeitsauflösung bezogen, nahmen den schädlichen Code automatisch auf.

2. Trivy

Trivy ist ein weit verbreiteter Open-Source-Schwachstellenscanner, der über eine GitHub Action in CI/CD-Pipelines integriert wird. Tausende Entwicklungsprojekte nutzen ihn, um Container-Images und Infrastruktur-Code vor der Bereitstellung zu scannen. Er wird eingesetzt, um Schwachstellen in Container-Images und cloud-nativen Artefakten zu erkennen. Viele Unternehmen nutzen ihn unter anderem für:

• CI/CD-Pipelines, um verwundbare Builds zu blockieren
• Container-Registry-Scans
• Infrastructure-as-Code-Validierung
• Compliance-Workflows

Ende März 2026 kaperten Angreifer Komponenten von Trivy GitHub Actions. Dadurch erhielten sie Zugriff auf ein hochprivilegiertes Automatisierungskonto, das zur Verwaltung von Releases genutzt wurde. Von dort aus konnten sie ein Publishing-Token stehlen, das ihnen dieselben Berechtigungen wie einem vertrauenswürdigen Maintainer gewährte. Obwohl Aqua Security nach der Offenlegung Zugangsdaten rotierte, behielten die Angreifer Zugriff auf gültige Tokens.

Am 19. März nutzten die Angreifer die gestohlenen Automatisierungszugangsdaten, um fast alle offiziellen Release-Referenzen für Trivys GitHub-Integration unauffällig durch schädliche Versionen des Codes zu ersetzen. Für alle, die das Tool über normale Automatisierungsprozesse installierten oder aktualisierten, wirkte nichts ungewöhnlich; sie bezogen scheinbar legitime Releases.

Entscheidend ist, dass der legitime Trivy-Scan danach weiterhin lief und die erwarteten Ergebnisse erzeugte. Im Scanner-Engine selbst wurde keine Schwachstelle ausgenutzt. Die veränderte Version der Trivy-Integration war jedoch darauf ausgelegt, sensible Informationen aus jedem Build-System abzugreifen, das sie ausführte. Sie durchsuchte die Build-Umgebung nach gespeicherten Cloud-Zugangsdaten, SSH-Schlüsseln und anderen Geheimnissen, verschlüsselte die Daten und sendete sie an einen von den Angreifern kontrollierten Server.

Die Kompromittierung erfolgte in der Release- und Automatisierungsschicht, genauer gesagt im Verteilungsmechanismus der GitHub Action, auf den nachgelagerte CI-Pipelines vertrauten.

3. LiteLLM

LiteLLM fungiert als Proxy-Schicht, die es Anwendungen ermöglicht, über eine einheitliche Schnittstelle mit mehreren Large-Language-Model-Anbietern zu kommunizieren. In vielen KI-gestützten Unternehmen kann LiteLLM zwischen folgenden Bereichen sitzen:

• Kundengerichteten KI-Funktionen
• Internen Wissensassistenten
• Automatisierten Entscheidungs-Engines
• API-gesteuerten KI-Workflows

Kurz gesagt: LiteLLM verarbeitet häufig Anfragen, die API-Schlüssel, Zugangsdaten, Prompts, proprietäre Daten und interne Konfigurationsdetails enthalten.

Bei dem gemeldeten Vorfall wurden schädliche Versionen von LiteLLM auf PyPI hochgeladen. In einer interessanten, Ökosystem-übergreifenden Verbindung zum Trivy-Vorfall begann diese Kompromittierung, als LiteLLMs CI-Pipeline die kompromittierte Trivy GitHub Action ausführte.

Als die manipulierte Trivy Action in LiteLLMs CI-Umgebung ausgeführt wurde, sammelte sie Geheimnisse aus dem CI-Runner, darunter PyPI-Publishing-Tokens und GitHub Personal Access Tokens. Diese gestohlenen Zugangsdaten wurden dann verwendet, um die schädlichen Versionen 1.82.7 und 1.82.8 auf PyPI zu veröffentlichen.

Die schädlichen LiteLLM-Versionen brachten eine dreistufige Payload mit:

• Abgreifen von Zugangsdaten aus mehr als 50 Kategorien von Geheimnissen
• Tooling für laterale Bewegungen in Kubernetes
• Eine persistente Hintertür, die Remote Code Execution ermöglichte

Auch hier wurde keine Schwachstelle in LiteLLMs Proxy-Logik in der Produktion ausgenutzt. Die Kompromittierung erfolgte als nachgelagerte Folge eines kompromittierten Sicherheitstools, das in die CI-Pipeline eingebettet war. Anschließend übernahmen automatisierte CI/CD-Pipelines, die die neueste Paketversion von LiteLLM bezogen, den schädlichen Code, ohne dass Angreifer Unternehmensumgebungen direkt kompromittieren mussten.

Wie sich das Software-Lieferkettenrisiko verändert

In den letzten Jahren wurde das Software-Lieferkettenrisiko weitgehend im Zusammenhang mit verwundbarem Code oder der Kompromittierung vertrauenswürdiger Software betrachtet. Denken Sie an Log4Shell und MOVEit – oder an die Kompromittierung des Build-Systems bei SolarWinds. Das Muster war vertraut: Ein Fehler oder eine vorgelagerte Kompromittierung lag in weit verbreiteter Software vor, Angreifer entdeckten oder nutzten sie aus, und Organisationen bemühten sich, zu patchen oder zu reagieren, bevor sich die Kompromittierung weiter ausbreitete.

Diese drei aktuellen Vorfälle zeigen, dass Angreifer die Systeme ins Visier nehmen, die Softwarekomponenten bauen, signieren, taggen, veröffentlichen und verteilen. Moderne Softwareentwicklung ist hochgradig automatisiert. Code wird zusammengeführt, getestet, paketiert und über CI/CD-Pipelines veröffentlicht. Pakete werden automatisch über Abhängigkeitsmanager bezogen. GitHub Actions, PyPI, npm und Container-Registries dienen als vertrauenswürdige Verteilungskanäle.

Diese Systeme sind auf Geschwindigkeit und implizites Vertrauen ausgelegt. Angreifer haben erkannt, dass die Kompromittierung dieser Schicht einen unverhältnismäßig großen Hebel bietet.

Anstatt:

• eine Zero-Day-Schwachstelle zu entdecken
• eine zuverlässige Exploit-Kette zu entwickeln
• jede Organisation einzeln anzugreifen

können sie:

• die Identität eines Maintainers kompromittieren
• ein Publishing-Token stehlen
• Release-Tags manipulieren
• einen CI-Workflow vergiften

und dann zulassen, dass die Automatisierung den schädlichen Code in großem Maßstab verbreitet. Jede CI-Pipeline, jeder automatisierte Build und jedes Abhängigkeits-Update ist Teil dessen, was effektiv eine Softwarefabrik ist. Es ist eine Produktionslinie, die Quellcode mit hoher Geschwindigkeit in bereitgestellte Systeme verwandelt.

Diese Fabrik betreibt heute umsatzgenerierende Anwendungen, Kundenplattformen, Logistiksysteme, KI-Dienste, Zahlungsintegrationen und Cloud-Infrastrukturen. Für viele Organisationen ist sie ebenso kritisch wie ein Produktionswerk oder eine Energieversorgungskette.

Dennoch ist die Governance dieser Softwarefabrik nicht im gleichen Tempo gereift wie ihre operative Bedeutung. Ein weiteres prägendes Merkmal dieser Entwicklung ist die systemische Vernetzung. Wenn ein vorgelagertes Tool kompromittiert wird, wird diese Vertrauensbeziehung selbst zu einem Ausbreitungsmechanismus.

Wenn sich das Bedrohungsmodell von Software-Lieferkettenangriffen von der Ausnutzung von Code hin zur Ausnutzung von Verteilungsautorität verschiebt, könnte der schwächste Punkt sehr wohl die Governance-Schicht rund um Anwendungen werden: strukturierte Governance für Identitäten, Release-Berechtigungen, Drittanbieter-Tools und Automatisierungskontrollen. Ein reifes GRC-Framework bringt diese technischen Schutzmaßnahmen mit den geschäftlichen Risikoprioritäten in Einklang.

Was Unternehmen jetzt daraus ableiten sollten

Deshalb kann das Software-Lieferkettenrisiko nicht länger als eng begrenztes Problem der Anwendungssicherheit betrachtet werden. Es ist ein Governance-Thema an der Schnittstelle von Identität, Release-Berechtigung, Drittanbieter-Tools und Automatisierung. Organisationen, die diese Exponierung reduzieren wollen, brauchen mehr als nur schnelleres Patchen. Sie brauchen klarere Verantwortlichkeiten, stärkere Kontrollen über Build- und Release-Prozesse und bessere Transparenz darüber, wo Vertrauen standardmäßig vererbt wird.

Wenn Ihre Organisation ihre Exponierung gegenüber dem Software-Lieferkettenrisiko überprüft, kontaktieren Sie uns jetzt.