Wer eine Build-Pipeline absichern will, landet schnell bei drei oder vier Werkzeugen: eines scannt Container-Images, eines prüft Abhängigkeiten, eines schaut sich Terraform-Code an. Trivy von Aqua Security deckt diese Fälle in einem einzigen Binary ab. Genau das macht es für viele Teams zum einfachsten Einstieg in automatisierte Sicherheitsprüfungen.

Was Trivy alles scannt

Trivy kennt mehrere Scan-Ziele. Mit trivy image prüft es Container-Images, mit trivy fs ein lokales Verzeichnis, mit trivy repo ein Git-Repository und mit trivy config Infrastructure-as-Code-Dateien. Gefunden werden Schwachstellen in Betriebssystem-Paketen und in Sprach-Abhängigkeiten wie npm, pip oder Go-Modulen, dazu Fehlkonfigurationen in Terraform, CloudFormation, Kubernetes-Manifesten und Dockerfiles. Auch hartkodierte Secrets und Lizenzprobleme erkennt Trivy auf Wunsch im selben Lauf.

Images scannen

Der einfachste Aufruf braucht nur den Image-Namen:

trivy image nginx:1.27

Das Ergebnis ist eine Tabelle mit CVE-Nummern, betroffenen Paketen und Schweregraden. In der Praxis will man das Rauschen sofort eindämmen:

trivy image --severity HIGH,CRITICAL --ignore-unfixed registry.example.com/app:1.4.2

Die Option --ignore-unfixed blendet Schwachstellen aus, für die es noch keinen Patch gibt. Das klingt erst mal falsch, ist aber sinnvoll: Ein Finding ohne verfügbaren Fix erzeugt keine umsetzbare Aufgabe und blockiert sonst nur die Pipeline.

IaC und Dockerfiles prüfen

Der zweite große Anwendungsfall ist die Konfigurationsprüfung:

trivy config ./infrastructure

Trivy meldet dann typische Fehlkonfigurationen: ein S3-Bucket ohne Verschlüsselung, ein Container der als root läuft, ein Dockerfile mit ungepinntem Base-Image, ein Security-Context der Privilege Escalation erlaubt. Die Checks basieren auf mitgelieferten Policies. Wer eigene Regeln braucht, kann sie in Rego schreiben und mit --config-policy einbinden.

In der Pipeline

Interessant wird Trivy erst, wenn es bei jedem Build automatisch läuft. In GitHub Actions sieht das so aus:

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t app:${{ github.sha }} .
      - name: Trivy Image-Scan
        uses: aquasecurity/trivy-action@0.28.0
        with:
          image-ref: app:${{ github.sha }}
          severity: HIGH,CRITICAL
          ignore-unfixed: true
          exit-code: 1
      - name: Trivy IaC-Scan
        uses: aquasecurity/trivy-action@0.28.0
        with:
          scan-type: config
          scan-ref: ./infrastructure
          exit-code: 1

Mit exit-code: 1 bricht der Build ab, sobald ein Finding im gewählten Schweregrad auftaucht. Damit wird aus einem Report ein Gate.

Rauschen kontrollieren statt ignorieren

Ein Scanner, der ständig rot ist, wird nach zwei Wochen abgeschaltet oder überstimmt. Deshalb lohnt ein gestufter Einstieg: erst einige Wochen im Report-Modus mit exit-code: 0 laufen lassen und die Ergebnisse sichten, dann nur CRITICAL blockieren, später HIGH dazunehmen. Bewusst akzeptierte Findings gehören in eine .trivyignore-Datei im Repository, jeweils mit Kommentar warum. So bleibt die Entscheidung nachvollziehbar und wandert mit dem Code durch die Versionskontrolle.

Einordnung

Trivy ergänzt sich gut mit den Werkzeugen aus früheren Beiträgen hier im Blog: Es kann SBOMs im CycloneDX-Format erzeugen und verarbeiten, ähnlich wie Syft und Grype, deckt aber zusätzlich den IaC-Bereich ab. Was Trivy nicht leistet, ist der Prozess dahinter. Ein Scan liefert Findings, aber keine Priorisierung, keine Zuständigkeit und keinen Nachweis gegenüber Kunden oder Auditoren. Wie aus Scan-Ergebnissen belastbare Nachweise werden, ist Thema drüben auf digital-business.blog. Für den technischen Einstieg gilt: ein Binary installieren, zwei Befehle in die Pipeline, und Images wie Infrastruktur-Code sind bei jedem Build geprüft.