Wenn das Werkzeug, das nach Bedrohungen sucht, selbst zur Bedrohung wird
Trivy ist einer der am weitesten verbreiteten Open-Source-Vulnerability-Scanner der Welt. Gepflegt von Aqua Security, ist er in Tausende von CI/CD-Pipelines für Container-Image-Scanning, Dateisystemanalyse und SBOM-Generierung integriert. Es ist das Werkzeug, dem man implizit vertraut — schließlich scannt es eigene Images auf die Schwachstellen anderer.
Was passiert also, wenn Trivy selbst zum Supply-Chain-Angriffsvektor wird? Das ist keine Hypothese. Anfang 2026 setzte ein gezielter Angriff auf den trivy-action GitHub Actions Workflow Organisationen, die automatisierte Sicherheitsscans durchführten, erheblichen Risiken aus: Anmeldedatendiebstahl, Pipeline-Manipulation und stille Scan-Unterdrückung waren die Folge. Der Vorfall ist ein Lehrbuchbeispiel dafür, warum Vertrauen in einen Toolnamen nicht dasselbe ist wie Vertrauen in seine Integrität zur Laufzeit.
Dieser Beitrag erläutert, was passiert ist, wie der Angriff technisch funktioniert hat, und welche defensiven Maßnahmen wirklich wichtig sind. Nicht theoretische. Praktische, die Sie diese Woche umsetzen können.
Was ist Trivy und warum ist es hier relevant
Trivy führt statische Analysen von Container-Images, Git-Repositories, Dateisystemen, Kubernetes-Clustern und Cloud-Konfigurationen durch. Seine GitHub Action — aquasecurity/trivy-action — ist in CI/CD-Pipelines von Unternehmen verankert, die alles von Fintech-Workloads bis hin zu kritischer Infrastruktur betreiben. Die Action wurde über 4.000 Mal geforkt und wird in Millionen von Workflow-Läufen pro Monat referenziert.
Genau diese Allgegenwärtigkeit macht sie zu einem attraktiven Ziel. Wird eine weit verbreitete GitHub Action kompromittiert, hat man einen Fuß in den Pipelines von Organisationen, die niemals auf eine Phishing-E-Mail hereinfallen würden, aber bereitwillig eine ungepinnte Action-Referenz aus einem öffentlichen Registry ziehen. Die Angriffsfläche ist nicht der Scanner selbst — es ist die Vertrauensbeziehung zwischen dem Tool und der Pipeline, die es nutzt.
Der Trivy-Sicherheitsvorfall: Was wir wissen
Der Vorfall folgte einem Muster, das MITRE ATT&CK unter T1195.001 kategorisiert. Ein Angreifer erhielt Schreibzugriff auf eine Abhängigkeit des trivy-action-Workflows. Anstatt Trivys Kernbinärdatei zu modifizieren — was Hash-Verifizierungsfehler ausgelöst hätte — injizierte der Angreifer schädliche Logik auf der Workflow-Orchestrierungsebene, speziell im Einstiegspunkt-Skript der Action.
Das Payload war subtil. Es ließ Scans nicht abstürzen und produzierte keine offensichtlich falschen Ergebnisse. Stattdessen schleusten es Umgebungsvariablen — einschließlich Secrets — über DNS-Exfiltration an eine vom Angreifer kontrollierte Domain aus. Organisationen, die Standard-Muster zur GitHub Actions Secret-Injektion verwenden, waren direkt exponiert, wenn diese Secrets im Scope des Runners waren.
Das sekundäre Payload war möglicherweise noch gefährlicher: selektive Scan-Unterdrückung. Für bestimmte Image-Digests gab die Action saubere Ergebnisse zurück — unabhängig von den tatsächlichen Schwachstellenbefunden. Das Tool meldete, alles sei in Ordnung. War es aber nicht.
Die technische Anatomie des Angriffs
Schritt 1: Ungepinnte Referenzen
Der erste Vektor nutzte die gängige Praxis, GitHub Actions per Tag statt per Commit-SHA zu referenzieren. Tags sind veränderlich. Ein Angreifer mit Schreibzugriff kann ein Tag auf einen anderen Commit verschieben, ohne dass nachgelagerte Konsumenten es bemerken. Die Lösung ist trivial: auf eine vollständige Commit-SHA pinnen.
Schritt 2: Secret-Exfiltration via DNS-Tunneling
Das schädliche Skript zählte die für den Runner verfügbaren Umgebungsvariablen auf. Der Exfiltrationsmechanismus nutzte DNS-Abfragen, die Secret-Werte als Subdomainlabels codierten. DNS-Verkehr erhält selten die gleiche Prüfung wie HTTP/S-Egress.
Schritt 3: Ergebnismanipulation
Die Action rief eine Remote-JSON-Konfigurationsdatei vom Angreifer-CDN ab. Für Images, deren Digest mit einem Eintrag in der Sperrliste übereinstimmte, schrieb die Action eine leere SARIF-Ergebnisdatei. CI/CD-Pipelines sahen null Befunde — ein sauberes Sicherheitsattest für potenziell anfällige Images.
Defensive Maßnahmen, die wirklich funktionieren
Actions auf Commit-SHAs pinnen
Nicht verhandelbar. Jede GitHub Action in Ihren Workflows sollte auf eine unveränderliche Commit-SHA verweisen. Diese einzelne Kontrolle hätte den Trivy-Vorfall neutralisiert.
Scanner-Output unabhängig validieren
Verwenden Sie niemals einen einzigen Scanner als harte Produktions-Gate. Container Image Scanning auf Plattformebene bietet die nötige Unabhängigkeit.
Runner-Berechtigungen aggressiv einschränken
Ausgehender Netzwerkzugriff von Runnern sollte über einen Egress-Proxy gefiltert werden, der DNS-Abfragen protokolliert. Vulnerability Management Programme, die CI/CD-Pipeline-Sicherheit als in-scope behandeln, erkennen Verhaltensabweichungen frühzeitig.
Supply-Chain-Sicherheit 2026
CISAs 2026 Secure Software Supply Chain-Leitfaden nennt CI/CD-Tooling als Hochrisikokomponentenkategorie. Policy-as-Code-Durchsetzung kann diese Kontrollen automatisch in Ihre Pipeline-Governance kodifizieren. SAST-Tooling kann auch Workflow-Dateien selbst auf Sicherheitsfehlkonfigurationen scannen — ungepinnte Actions und unsichere Secret-Handhabungsmuster abfangen, bevor sie den Hauptbranch erreichen.
Vertrauen in Ihre Scanning-Infrastruktur wiederherstellen
Die richtige Antwort nach einem Vorfall ist eine Sicherheitsarchitektur, bei der die Kompromittierung eines einzigen Tools nicht die gesamte Erkennungsfähigkeit stumm schalten kann. Secret Detection sollte unabhängig von Trivy laufen, nicht als Plugin darin.