Trivy: Scanner und Targets in einem Go-Werkzeug

Warum aquasecurity/trivy Targets und Scanner trennt

Trivy löst ein konkretes Problem: Sicherheitsprüfungen sind normalerweise auf viele Einzelwerkzeuge verteilt, einer für Pakete, einer für Geheimnisse, einer für Fehlkonfigurationen. Das Projekt von Aqua Security fasst diese Aufgaben in einem in Go geschriebenen Binary zusammen. Das README beschreibt die Architektur über zwei Achsen. Targets sind die Objekte, die geprüft werden: Container-Images, Dateisysteme, entfernte Git-Repositories, Images virtueller Maschinen und Kubernetes. Scanner sind die Kategorien, nach denen gesucht wird: Betriebssystempakete und genutzte Softwareabhängigkeiten als SBOM, bekannte Schwachstellen als CVEs, Probleme in Infrastructure-as-Code, sensible Informationen und Geheimnisse sowie Softwarelizenzen.

Diese Trennung hat praktische Folgen. Wer ein Dateisystem auf drei Kategorien prüfen will, kombiniert die Scanner per Flag, statt drei Tools zu installieren und drei Ausgaben zusammenzuführen. Für die vollständige Sprach- und Plattformabdeckung verweist das README auf eine externe Seite namens Scanning Coverage; welche Sprachen im Einzelnen unterstützt werden, steht dort, nicht im Repository-Readme. Die Metadaten zeigen 37.674 Sterne und 635 Forks, laut README ist Trivy ein Open-Source-Projekt von Aqua Security.

Installation über brew install trivy und docker run aquasec/trivy

Drei Wege führt das README namentlich auf: brew install trivy für macOS-Anwender, docker run aquasec/trivy als Container ohne lokale Installation und den Binärdownload von github.com/aquasecurity/trivy/releases/latest. Die vollständige Liste der Installationsoptionen liegt auf der Installationsseite der Dokumentation unter trivy.dev; das README wiederholt sie nicht, sodass etwa distributionsspezifische Paketquellen dort nachzulesen sind.

Für CI-Umgebungen ist der Container-Weg naheliegend, weil keine Abhängigkeiten im Runner landen und die Version über das Image-Tag fixiert bleibt. Wer lokal arbeitet, nimmt in der Regel Homebrew oder das Binary. Eine Anmerkung zur Projektaktivität: Die Metadaten weisen 258 offene Issues aus, was bei einem Projekt dieser Größe normal ist, und das README empfiehlt für Fragen und Kontakt GitHub Discussions. Eine Antwortzeit oder ein Supportversprechen nennt die Quelle nicht.

Die Syntax trivy <target> [--scanners ...] und drei README-Beispiele

Das README gibt eine allgemeine Form an: trivy <target> [--scanners <scanner1,scanner2>] <subject>. Daraus folgen drei Beispiele. trivy image python:3.4-alpine prüft ein Container-Image. trivy fs --scanners vuln,secret,misconfig myproject/ scannt ein Verzeichnis und schaltet drei Scanner gezielt ein. trivy k8s --report summary cluster erzeugt einen zusammengefassten Bericht für einen Cluster.

Das Flag --scanners ist die zentrale Steuerung: Wer nur Geheimnisse oder nur Lizenzfragen suchen will, reduziert die Prüfung auf die passende Kategorie. Der Parameter --report summary beim Kubernetes-Aufruf deutet darauf hin, dass Vollberichte für Cluster schnell unhandlich werden, weshalb eine Zusammenfassung angeboten wird. Wie die Ausgabe im Einzelnen aussieht, welche Spalten die Tabelle hat und welche Exit-Codes CI-Pipelines auswerten können, beschreibt das README nicht; dafür ist die Dokumentation unter trivy.dev zuständig. Genau das sollten Anwender vor der Integration prüfen, denn ein Scanner ohne definierte Exit-Code-Semantik lässt sich in Pipelines schwer automatisieren.

Canary-Builds bei jedem Push auf main: Teststrom statt Releasekanal

Für jeden Push auf den Hauptzweig erzeugt das Projekt Canary-Builds. Das README nennt vier Verteilwege: Docker-Hub-Images, Images in der GitHub Container Registry, Amazon-ECR-Images und Binärdateien aus einem GitHub-Actions-Workflow. Ausdrücklich warnt das Projekt, dass Canary-Builds kritische Fehler enthalten können und für die Produktion nicht empfohlen werden.

Der praktische Nutzen liegt im Nachvollziehen von Fixes: Wer prüfen will, ob ein Problem im Hauptzweig bereits behoben ist, greift zu einem Canary-Image, statt auf das nächste Release zu warten. Für produktive Pipelines gilt umgekehrt, eine feste Release-Version zu pinnen. Das Tempo ist hoch: v0.72.0 erschien am 30. Juni 2026, v0.73.0 am 3. August und v0.74.0 am 14. August 2026. Bei einem solchen Rhythmus lohnt es sich, vor jedem Upgrade die Release-Notizen gegenzulesen, weil sich Verhalten zwischen zwei Versionen schneller ändern kann als bei Projekten mit Jahrestakt.

trivy-action, trivy-operator oder VS-Code-Plugin: drei Integrationswege

Das README verweist auf drei konkrete Integrationen mit eigenen Repositories: die GitHub-Actions-Anbindung aquasecurity/trivy-action, den Kubernetes-Operator aquasecurity/trivy-operator und das VS-Code-Plugin aquasecurity/trivy-vscode-extension. Sie decken unterschiedliche Einsatzpunkte ab, und die Wahl hängt davon ab, wann ein Befund auftauchen soll.

trivy-action prüft im Moment des Builds und kann die Pipeline bei Funden stoppen. Der trivy-operator läuft dauerhaft im Cluster und überwacht laufende Workloads, also auch Images, die längst deployt sind und nie wieder eine Pipeline durchlaufen. Für ein neues Image im Build ist die Action der richtige Ort, für die laufende Überwachung eines Bestands der Operator; beides zusammen kostet Betriebsaufwand im Cluster. Das Plugin verschiebt Befunde in den Editor und passt zu Entwicklern, die beim Schreiben sehen wollen, welche Abhängigkeit ein CVE auslöst. Als Alternative zu all dem nennt das README die kommerzielle Aqua-Plattform, die auf Trivy aufbaut und über eine Vergleichstabelle abgegrenzt wird, deren Inhalt die Quelle nicht wiedergibt.

Apache-2.0 und was die README zu Trivy v0.74.0 ausspart

Trivy steht unter der Apache-Lizenz 2.0, einer permissiven Lizenz, die kommerzielle Nutzung und eigene Distribution erlaubt; für Unternehmen, die den Scanner in eigene Images einbetten wollen, folgt daraus keine Pflicht zur Offenlegung eigener Quellen. Das Repository ist in Go geschrieben und nicht archiviert, der letzte Push lag zum Abrufzeitpunkt am 14. August 2026, demselben Tag wie Release v0.74.0.

Einige Fragen bleiben in dieser Quelle offen. Das README nennt keine Ausgabeformate, keine Exit-Codes und keine Strategie für die Aktualisierung der Schwachstellendatenbank, obwohl ein CVE-Scanner ohne frische Daten wenig wert ist; solche Antworten stehen in der Dokumentation, nicht im Readme. Die Selbstbeschreibung als umfassender und vielseitiger Scanner stammt vom Hersteller und ist als selbst berichtet zu lesen. Wer die Abdeckung für seine Kombination aus Sprache und Plattform braucht, muss die Scanning-Coverage-Seite auf trivy.dev prüfen, denn ausgerechnet der Umfang des Kernversprechens liegt außerhalb des Readme.

Redaktionelles Fazit

Trivy passt für Teams, die einen einzigen Scanner über Container-Images, Repositories und Kubernetes legen wollen und Flags wie --scanners gezielt setzen; wer nur Secrets in einem Verzeichnis sucht, kommt mit kleineren Spezialwerkzeugen ebenfalls aus. Vor der Einführung einen Probelauf fahren: trivy image gegen ein reales Image aus der eigenen Registry ausführen, die Ausgabe gegen die Dokumentation unter trivy.dev abgleichen und klären, welche Exit-Codes die eigene CI auswerten kann. Wer laufende Cluster überwachen will, schaut sich zusätzlich den trivy-operator an.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes