Supply-Chain-Angriff auf Trivy: Wenn der Sicherheitsscanner selbst zur Waffe wird
8 Min. Lesezeit
Am 19. März 2026 wurde der populäre Vulnerability-Scanner Trivy selbst zum Angriffsvektor. 75 von 76 Version-Tags im GitHub-Repository wurden kompromittiert, ein manipuliertes Binary stahl SSH-Keys, Cloud-Credentials und Kubernetes-Secrets aus CI/CD-Pipelines. Der Angriff zeigt ein Muster das sich 2026 verschärft: Angreifer zielen nicht mehr auf Anwendungen – sie zielen auf die Werkzeuge, die Anwendungen absichern sollen.
Laut BSI-Lagebericht 2025 haben sich Supply-Chain-Angriffe in Deutschland verdoppelt. Die durchschnittliche Erkennungszeit liegt bei 287 Tagen – fast zehn Monate, in denen kompromittierter Code unbemerkt in Produktionsumgebungen läuft. Wer Software entwickelt, einkauft oder betreibt, muss die eigene Lieferkette als Angriffsfläche begreifen. Dieser Artikel zeigt anhand aktueller Fälle, was passiert, welche Muster sich wiederholen – und was konkret hilft.
Das Wichtigste in Kürze
- Trivy-Angriff März 2026: 75 Version-Tags kompromittiert, dreistufiger Infostealer extrahierte CI/CD-Secrets an eine Typosquatting-Domain. Betroffen: Tausende DevSecOps-Teams weltweit (Aqua Security, CrowdStrike, Wiz).
- 156 Prozent mehr bösartige Open-Source-Pakete im Jahresvergleich. Seit 2019 wurden über 704.000 Schadpakete identifiziert (Sonatype 2024).
- 74 Prozent aller Codebasen enthalten hochriskante Open-Source-Schwachstellen (Synopsys OSSRA 2024).
- SBOM wird Pflicht: Der EU Cyber Resilience Act verpflichtet Hersteller zur maschinenlesbaren Software-Stückliste. Hauptpflichten ab Dezember 2027, Meldepflichten ab September 2026.
- BSI: 119 neue Schwachstellen pro Tag – ein Plus von 24 Prozent. 48 Prozent der KRITIS-Betreiber ohne Angriffserkennung (BSI Lagebericht 2025).
Der Trivy-Angriff: Wenn der Scanner zum Trojaner wird
Trivy ist einer der meistgenutzten Open-Source-Vulnerability-Scanner im DevSecOps-Bereich. Er prüft Container-Images, Dateisysteme und IaC-Templates auf Schwachstellen – und läuft in Tausenden CI/CD-Pipelines als GitHub Action. Genau dort setzten die Angreifer an.
Die Gruppe „TeamPCP“ kompromittierte Ende Februar 2026 zunächst GitHub-Actions-Credentials des Trivy-Projekts. Die erste Reaktion von Aqua Security blieb unvollständig – die Credential-Rotation deckte nicht alle Zugänge ab. Am 19. März folgte die zweite Welle: 75 von 76 Version-Tags im Repository aquasecurity/trivy-action wurden per Force-Push auf Schadcode umgeleitet. Alle sieben Tags in aquasecurity/setup-trivy waren ebenfalls betroffen.
Der eingeschleuste Code arbeitete in drei Stufen. Erstens: Abgreifen von Umgebungsvariablen und Credentials aus dem CI/CD-Runner-Speicher. Zweitens: Verschlüsselung sensibler Daten – SSH-Keys, Cloud-Credentials, Datenbank-Tokens, Kubernetes-Secrets. Drittens: Exfiltration an die Typosquatting-Domain scan.aquasecurtiy[.]org – ein bewusst falsch geschriebener Domainname.
Die Ironie: Ein Tool das Schwachstellen finden soll, wurde selbst zur Schwachstelle. Der Angriff hätte durch SHA-basiertes Pinning von GitHub Actions weitgehend verhindert werden können. Wer statt trivy-action@v0.35.0 einen konkreten Commit-Hash referenziert hätte, wäre vom Tag-Poisoning nicht betroffen gewesen.
Das Muster: XZ Utils, 3CX und die Langzeitstrategie
Supply-Chain-Angriffe folgen zunehmend einem Muster: Vertrauen aufbauen, Infrastruktur kompromittieren, breit streuen.
Das drastischste Beispiel ist die XZ-Utils-Backdoor vom März 2024 (CVE-2024-3094, CVSS 10.0). Ein Angreifer mit dem Pseudonym „Jia Tan“ baute über drei Jahre hinweg Vertrauen beim Maintainer der weit verbreiteten Kompressionsbibliothek auf. Am Ende implantierte er eine Backdoor die Remote Code Execution über OpenSSH ermöglichte – in einer Komponente die auf praktisch jedem Linux-Server läuft. Entdeckt wurde der Angriff durch Zufall: Der PostgreSQL-Entwickler Andres Freund bemerkte eine ungewöhnliche Verzögerung bei SSH-Logins.
Beim 3CX-Angriff (März 2023) dokumentierte Mandiant erstmals eine „Double Supply Chain Compromise“: Die Lazarus-Gruppe kompromittierte zuerst die Trading-Software X_Trader, infizierte darüber einen 3CX-Mitarbeiter und manipulierte dann die Build-Umgebungen. Die signierte Desktop-App wurde an 600.000 Unternehmen mit 12 Millionen Nutzern ausgeliefert.
Das gemeinsame Muster aller drei Fälle: Der Angriffsvektor war nicht die Anwendung – sondern die Infrastruktur dahinter. Build-Systeme, Code-Repositories, Dependency-Registries. Wer nur seine eigene Anwendung absichert aber die Werkzeuge und Abhängigkeiten blind vertraut, hat eine offene Flanke die zunehmend ausgenutzt wird. Gartner prognostizierte 2022, dass bis 2025 45 Prozent aller Organisationen Angriffe auf ihre Software-Lieferketten erleben würden. Eine BlackBerry-Umfrage 2024 ergab: Es sind bereits 75 Prozent.
„Das Management von Lieferketten-Risiken ist nach wie vor eines der grössten Probleme für CISOs.“
– Philip Reitinger, CEO Global Cyber Alliance, sinngemäss (SecurityWeek Cyber Insights 2024)
Die Zahlen: Warum das Problem exponentiell wächst
Der Sonatype State of Software Supply Chain Report 2024 dokumentiert einen Anstieg bösartiger Open-Source-Pakete um 156 Prozent im Jahresvergleich. Seit 2019 wurden insgesamt über 704.000 Schadpakete in Registries wie npm, PyPI und Maven identifiziert – mehr als 512.000 davon allein seit November 2023.
Der Synopsys OSSRA Report 2024 ergänzt: 96 Prozent der untersuchten Codebasen enthalten Open-Source-Komponenten. 84 Prozent enthalten mindestens eine bekannte Schwachstelle. 74 Prozent enthalten hochriskante Schwachstellen – ein Sprung von 54 Prozent gegenüber dem Vorjahr. Und 91 Prozent nutzen Komponenten die zehn oder mehr Versionen veraltet sind.
Dazu kommt ein neues Phänomen: „Slopsquatting“ – Angreifer nutzen die Tendenz von KI-Code-Assistenten, nicht existierende Package-Namen zu halluzinieren. Sie registrieren diese Namen und befüllen sie mit Schadcode. Wenn ein Entwickler den KI-Vorschlag ungeprüft übernimmt, wird die Malware automatisch installiert.
Das „Slopsquatting“-Problem ist besonders tückisch weil es mit der Verbreitung von KI-Coding-Assistenten wächst. Laut ReversingLabs zielten 2024 bereits 14 von 23 Krypto-bezogenen Malware-Kampagnen auf npm-Pakete. Im September 2025 wurden 20 npm-Pakete kompromittiert die zusammen über zwei Milliarden wöchentliche Downloads aufwiesen. Die Angriffsfläche vergrössert sich also nicht linear – sie wächst mit jedem neuen Paket das ein Entwickler installiert, mit jeder neuen Abhängigkeit die ein Build-System automatisch auflöst. Und 95 Prozent der Fälle, in denen Entwickler eine verwundbare Komponente nutzen, existiert laut Sonatype bereits eine gepatchte Version. Das Problem ist nicht die Verfügbarkeit von Fixes – es ist die mangelnde Aufmerksamkeit für Updates.
Die Kosten sind messbar: Laut IBM Cost of a Data Breach Report 2024 liegen die Durchschnittskosten einer Datenpanne bei 4,88 Millionen Dollar – ein Allzeithoch. Supply-Chain-Kompromittierungen lagen laut IBM-Auswertungen leicht darüber und waren der zweithäufigste Angriffsvektor.
Für deutsche Unternehmen verschärft sich die Lage durch zwei parallele Entwicklungen. Erstens: Die NIS2-Verordnung macht Supply-Chain-Sicherheit für rund 29.500 Unternehmen zur gesetzlichen Pflicht – inklusive persönlicher Geschäftsführerhaftung bei Versäumnissen. Zweitens: Der Fachkräftemangel in der IT-Sicherheit bedeutet, dass viele Unternehmen nicht genug Personal haben um ihre Abhängigkeiten systematisch zu prüfen. Das BSI berichtet, dass 80 Prozent der KRITIS-Betreiber zwar Informationssicherheits-Managementsysteme aufgebaut haben – aber erhebliche Defizite im Business-Continuity-Management bestehen. Wenn eine kritische Abhängigkeit kompromittiert wird und es keinen Incident-Response-Plan gibt, vergehen die 287 Tage bis zur Erkennung besonders schmerzhaft.
Warum klassische Security-Tools nicht reichen
Die meiste Unternehmenssicherheit basiert auf einem Modell das Supply-Chain-Angriffe nicht abdeckt: Perimeter-Schutz, Endpoint Detection, Netzwerk-Segmentierung. Diese Tools erkennen Malware die von aussen kommt – aber nicht Schadcode der über vertrauenswürdige Kanäle eingeschleust wird.
Beim Trivy-Angriff kam der Schadcode über ein Tool das explizit als Sicherheitsmassnahme eingesetzt wurde. Kein Virenscanner hätte Alarm geschlagen, kein Firewall-Log hätte eine Anomalie gezeigt. Der Angriff nutzte die normale CI/CD-Pipeline – die gleichen Pfade über die auch legitimer Code ausgeliefert wird. Für Intrusion-Detection-Systeme sah alles nach Business as Usual aus.
Deshalb versagen auch traditionelle Penetrationstests bei Supply-Chain-Risiken. Ein Pentest prüft die eigene Infrastruktur – nicht die Build-Systeme der Open-Source-Projekte die man als Abhängigkeit nutzt. Und ein Audit der eigenen Codebase findet keine Backdoor in einer upstream Dependency die 50 Versionen tief verschachtelt ist.
Was stattdessen nötig ist: Shift Left in der Supply Chain – Sicherheitsprüfungen nicht erst am Ende der Pipeline, sondern bei jeder einzelnen Abhängigkeit. Das bedeutet: Jedes Package wird beim Einzug in die Codebase geprüft, nicht erst beim Deployment. Jede GitHub Action wird per SHA gepinnt, nicht per Tag referenziert. Und jeder Build-Prozess wird kryptographisch signiert und verifiziert – bevor ein einziges Byte in Produktion geht.
Der Paradigmenwechsel ist vergleichbar mit der Einführung von Zero Trust in Netzwerken: Nicht mehr „alles innerhalb des Perimeters ist vertrauenswürdig“, sondern „nichts ist vertrauenswürdig bis es verifiziert ist“ – und das schliesst die eigenen Entwicklungswerkzeuge ein.
Deutschland: 119 Schwachstellen pro Tag und die SBOM-Pflicht
Der BSI-Lagebericht 2025 dokumentiert 119 neue Sicherheitsschwachstellen pro Tag im Berichtszeitraum – ein Anstieg von 24 Prozent. 461 Datenlecks mit deutschen Institutionen als Opfer. Und 48 Prozent der KRITIS-Betreiber verfügen über kein System zur Angriffserkennung.
Der EU Cyber Resilience Act (in Kraft seit 10. Dezember 2024) verpflichtet alle Hersteller von Produkten mit digitalen Elementen zur maschinenlesbaren SBOM. Hauptpflichten ab 11. Dezember 2027, Meldepflichten ab 11. September 2026. Verstösse: bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes.
Das BSI hat mit TR-03183-2 (August 2025) konkrete SBOM-Anforderungen definiert. Empfohlene Formate: SPDX und CycloneDX. Für NIS2-regulierte Unternehmen ist Supply-Chain-Sicherheit ohnehin explizit Teil der gesetzlichen Anforderungen.
In den USA gilt seit 2021 Executive Order 14028: Jeder Softwareanbieter der an die Bundesregierung liefert, muss eine SBOM vorlegen. Die Deadline für die Umsetzung war September 2023. Europa zieht mit dem CRA nach – und geht mit den Meldepflichten ab September 2026 sogar einen Schritt weiter als die US-Regelung. Für deutsche Mittelständler die sowohl in die USA als auch in die EU liefern, bedeutet das: SBOM ist nicht optional – es ist Marktzugangsvoraussetzung auf beiden Seiten des Atlantiks.
Die finanzielle Dimension ist erheblich: Laut IBM Cost of a Data Breach Report 2024 liegen die Durchschnittskosten eines Supply-Chain-Vorfalls bei knapp 5 Millionen Dollar. Für ein mittelständisches Unternehmen mit 500 Mitarbeitenden kann das existenzbedrohend sein – insbesondere wenn die Erkennungszeit bei fast zehn Monaten liegt und in dieser Zeit weitere Systeme kompromittiert werden. Dazu kommen die regulatorischen Folgen: Unter NIS2 drohen bei mangelhafter Supply-Chain-Sicherheit Bussgelder bis 10 Millionen Euro und persönliche Geschäftsführerhaftung. Unter dem CRA kommen nochmals bis zu 15 Millionen Euro hinzu. Die Kosten für Prävention – SBOM-Tooling, Dependency Scanning, ein halbes FTE für Supply-Chain-Security – liegen im niedrigen fünfstelligen Bereich pro Jahr. Das Verhältnis von Investition zu potenziellem Schaden rechtfertigt jede dieser Maßnahmen.
Was konkret schützt: Sechs Maßnahmen mit Evidenz
1. SHA-basiertes Dependency Pinning. Statt GitHub Actions per Tag zu referenzieren (@v1), den konkreten Commit-Hash pinnen. Tags können überschrieben werden, SHA-Hashes nicht. Der gesamte Trivy-Angriff wäre ins Leere gelaufen.
2. SBOM erstellen und pflegen. Wer nicht weiss welche Abhängigkeiten in der eigenen Software stecken, kann bei der nächsten CVE-Meldung nicht reagieren. Tools wie Syft generieren SBOMs automatisch aus Container-Images.
3. SLSA Level 2 implementieren. Das Supply-chain Levels for Software Artifacts Framework sichert die Build-Integrität ab. Level 2 – digital signierte Build-Provenance – ist mit cosign und GitHub-OIDC in wenigen Wochen erreichbar.
4. Dependency Scanning in der CI/CD-Pipeline. Automatisierte Prüfung jeder Abhängigkeit bei jedem Build. Tools: Dependabot, Snyk, Grype. Kein Push ohne grünen Security-Check.
5. Code Signing mit Sigstore. Kostenlos, Open Source, ermöglicht kryptographische Signaturen für Binaries und Pakete. Manipulationen werden nachweisbar.
6. Regelmässiges Vendor Risk Assessment. Nicht nur die eigene Software prüfen – auch die Lieferanten. Wer einen Vulnerability-Scanner einsetzt, sollte wissen ob dessen CI/CD-Pipeline gehärtet ist.
Die Kombination dieser sechs Maßnahmen bildet das Minimum für eine belastbare Supply-Chain-Sicherheit. Keine einzelne Massnahme reicht allein. SHA-Pinning ohne Dependency-Scanning erkennt keine bekannten Schwachstellen. SBOM ohne Vendor Assessment zeigt die eigenen Abhängigkeiten, aber nicht deren Sicherheitsstatus. Und Code Signing ohne SLSA beweist nur wer signiert hat – nicht ob der Build-Prozess sauber war. Die Stärke liegt in der Kombination: Transparenz (SBOM), Integrität (SLSA + Signing), Prüfung (Scanning + Assessment) und Härtung (Pinning).
Der entscheidende Punkt: Supply-Chain-Sicherheit ist kein Projekt das man einmal abschliesst. Es ist ein kontinuierlicher Prozess der in jeden Build, jedes Deployment und jede Beschaffungsentscheidung eingebaut werden muss. Der Trivy-Angriff hat gezeigt, dass selbst die Tools die Sicherheit garantieren sollen, kompromittiert werden können. Wer das verstanden hat, baut seine Verteidigung nicht auf Vertrauen auf – sondern auf Verifikation.
„Angriffe auf die Software-Lieferkette unserer globalen ICT-Infrastruktur werden häufiger, aggressiver und folgenschwerer.“
– CISA, Defending Against Software Supply Chain Attacks, sinngemäss
Die Lektion aus 2024, 2025 und dem ersten Quartal 2026 ist eindeutig: Software-Lieferketten sind die neue Hauptangriffsfläche. Wer sie ignoriert, verlässt sich auf Vertrauen in einer Welt die Verifikation verlangt. Der Trivy-Fall ist dabei besonders lehrreich – nicht weil er technisch neuartig war, sondern weil er zeigt dass auch die Verteidigungswerkzeuge selbst angreifbar sind. Die Antwort darauf ist nicht Misstrauen gegenüber Open Source. Es ist systematische Verifikation: Jede Abhängigkeit geprüft, jeder Build signiert, jede Änderung nachvollziehbar. Das ist aufwändig. Aber die Alternative – 287 Tage mit kompromittiertem Code in Produktion – ist es deutlich mehr.
Häufige Fragen
Was war der Trivy-Supply-Chain-Angriff?
Im März 2026 kompromittierte die Gruppe TeamPCP den Open-Source-Vulnerability-Scanner Trivy von Aqua Security. 75 von 76 Version-Tags im GitHub-Repository wurden auf Schadcode umgeleitet. Der eingeschleuste Code stahl CI/CD-Secrets wie SSH-Keys, Cloud-Credentials und Kubernetes-Tokens.
Was ist eine SBOM und warum wird sie Pflicht?
Eine Software Bill of Materials ist eine maschinenlesbare Stückliste aller Softwarekomponenten eines Produkts. Der EU Cyber Resilience Act macht sie ab Dezember 2027 zur Pflicht. Gängige Formate sind CycloneDX und SPDX.
Wie schütze ich mich vor Supply-Chain-Angriffen?
Die wichtigsten Maßnahmen: SHA-basiertes Pinning von Dependencies, automatisiertes Dependency-Scanning in der CI/CD-Pipeline, SBOM erstellen und pflegen, Code Signing mit Sigstore und regelmässiges Vendor Risk Assessment.
Was ist SHA-basiertes Pinning?
Statt eine GitHub Action per Version-Tag zu referenzieren (z.B. @v1), wird der konkrete Commit-Hash verwendet. Tags können von Angreifern überschrieben werden, SHA-Hashes nicht.
Wie lange bleiben Supply-Chain-Angriffe unentdeckt?
Laut BSI-Lagebericht 2025 liegt die durchschnittliche Erkennungszeit bei 287 Tagen. Bei der XZ-Utils-Backdoor dauerte die Vorbereitung sogar drei Jahre.
Welche deutschen Unternehmen sind betroffen?
Jedes Unternehmen das Software einsetzt oder betreibt. Besonders exponiert: Unternehmen unter NIS2-Regulierung (rund 29.500 in Deutschland) und KRITIS-Betreiber.
Was ist SLSA?
Supply-chain Levels for Software Artifacts – ein Stufenmodell für Build-Integrität. Level 2 lässt sich mit cosign und GitHub-OIDC in wenigen Wochen implementieren.
Lesetipps der Redaktion
Mehr aus dem MBF Media Netzwerk
Quelle Titelbild: Pexels / Tima Miroshnichenko (px:5380603)
