Wo Trivy im Sicherheits-Workflow hingehört
Trivy scannt fertige Container-Images, Dockerfiles, Infrastructure-as-Code und sogar Git-Repositories auf bekannte Schwachstellen (CVEs) — als ein Werkzeug für vier verschiedene Scan-Ziele. Der praktische Wert liegt weniger im einzelnen manuellen Scan als in der CI/CD-Integration: Ein Build mit kritischer Schwachstelle sollte gar nicht erst in Produktion gelangen, statt dass jemand das Ergebnis eines separaten Sicherheits-Scans Wochen später manuell durchgeht.
Trivy installieren
# Ubuntu/Debian per Repository (empfohlen fuer automatische Updates)
apt-get install -y apt-transport-https gnupg
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | gpg --dearmor > /usr/share/keyrings/trivy.gpg
echo "deb [signed-by=/usr/share/keyrings/trivy.gpg] https://aquasecurity.github.io/trivy-repo/deb generic main" \
> /etc/apt/sources.list.d/trivy.list
apt update && apt install -y trivy
trivy version
Docker Image scannen
# Lädt die Vulnerability-Datenbank beim ersten Lauf automatisch
trivy image nginx:stable-alpine
# Nur kritische und hohe CVEs (reduziert Rauschen deutlich)
trivy image --severity HIGH,CRITICAL nginx:latest
# JSON-Output für Weiterverarbeitung in CI/CD
trivy image --format json --output scan-results.json nginx:latest
# Nur Vulnerabilities mit verfügbarem Fix anzeigen
trivy image --ignore-unfixed nginx:latest
--ignore-unfixed ist in der Praxis fast immer sinnvoll: Ohne verfügbaren Patch kann ohnehin nichts sofort behoben werden, und die Warnung verstopft nur die Ergebnisliste. Wichtig ist trotzdem, unfixierte kritische CVEs im Blick zu behalten und regelmäßig erneut zu prüfen, ob inzwischen ein Fix erschienen ist.
Dockerfile auf Fehlkonfigurationen scannen
trivy config --severity HIGH,CRITICAL Dockerfile
Typischer Fund: "Last USER command is not to a non-root user" — ein Container, der als root läuft, ist bei einer Kompromittierung deutlich gefährlicher als einer mit eingeschränktem Benutzer. Fix im Dockerfile:
FROM nginx:stable-alpine AS final
RUN adduser -D -H appuser
USER appuser
Trivy prüft mit trivy config auch Kubernetes-Manifeste und Terraform-Code auf dieselbe Weise — dieselbe Logik, andere Eingabedateien.
In GitHub Actions integrieren
name: Container Security Scan
on: [push, pull_request]
jobs:
trivy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build Image
run: docker build -t meine-app:ci .
- name: Trivy Scan
uses: aquasecurity/trivy-action@master
with:
image-ref: 'meine-app:ci'
format: 'sarif'
output: 'trivy-results.sarif'
severity: 'CRITICAL,HIGH'
exit-code: '1'
- name: Upload SARIF
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: 'trivy-results.sarif'
exit-code: '1' ist die entscheidende Zeile — ohne sie läuft der Scan durch, meldet Funde, aber der Build wird trotzdem als erfolgreich markiert. Mit der Zeile bricht die Pipeline bei kritischen Funden ab, bevor ein verwundbares Image überhaupt gebaut oder deployt wird.
Filesystem und Secrets scannen
# Lokales Verzeichnis scannen (Node.js, Python, Go, etc. Abhängigkeiten)
trivy fs .
# Versehentlich eingecheckte Secrets finden
trivy fs --scanners secret .
# Findet: API-Keys, Passwörter, Private Keys direkt im Code
# Ganzes Git-Repository remote scannen
trivy repo https://github.com/firma/meine-app
Der Secret-Scan lohnt sich besonders als einmaliger Check bei der Übernahme fremder oder älterer Repositories — versehentlich eingecheckte Zugangsdaten aus Jahren zurückliegenden Commits bleiben in der Git-Historie bestehen, auch wenn die Datei längst wieder gelöscht wurde.
FAQ
Wie oft wird die Vulnerability-Datenbank aktualisiert?
Trivy lädt die DB automatisch bei jedem Lauf, sofern der lokale Cache älter als 24 Stunden ist. In CI-Umgebungen lässt sich mit einem vorgeladenen, gecachten DB-Verzeichnis die Scan-Zeit deutlich reduzieren.
Ersetzt Trivy ein vollständiges Vulnerability-Management?
Nein — Trivy findet bekannte CVEs in Images und Code, ist aber kein Ersatz für Laufzeit-Monitoring, Netzwerk-Segmentierung oder ein vollständiges Patch-Management-Programm.
Fazit
Trivy ist der pragmatischste Einstieg in automatisiertes CVE-Scanning: ein Werkzeug für Images, Dockerfiles, IaC und Code, direkt in CI/CD integrierbar, ohne separate Infrastruktur.
Ich integriere Sicherheits-Scans in CI/CD-Pipelines für Unternehmen in Heidelberg und der Rhein-Neckar-Region. Anfragen.