Image Scanning mit Trivy und Grype im Vergleich

1. Warum Image Scanning ein eigener Pflichtschritt ist

Image Scanning prüft jede Schicht eines Docker-Images gegen Datenbanken bekannter Schwachstellen, bevor das Image überhaupt in Produktion läuft. Ein Basis-Image wie `python:3.12-slim` bringt neben der eigentlichen Laufzeitumgebung auch Systembibliotheken mit, die eigene CVEs tragen können, unabhängig vom Anwendungscode. Ohne Image Scanning bleiben diese Schwachstellen unsichtbar, bis ein Sicherheitsvorfall oder ein externer Pentest sie aufdeckt.

Der entscheidende Vorteil von Image Scanning gegenüber reinem Code-Review ist, dass es transitive Abhängigkeiten erfasst, die kein Entwickler manuell im Blick behält: System-Pakete, Sprachpaketmanager-Abhängigkeiten wie Composer oder npm, und teilweise sogar Lizenzinformationen. Trivy und Grype sind die zwei am häufigsten eingesetzten Open-Source-Lösungen für Image Scanning, beide kostenlos, beide CI-tauglich, aber mit unterschiedlichen Stärken, die im Folgenden im Detail verglichen werden.

2. Trivy: Aufbau, Datenquellen und erster Scan

Trivy von Aqua Security ist ein Alles-in-einem-Scanner für Image Scanning, der neben Container-Images auch Dateisysteme, Git-Repositories, Kubernetes-Manifeste und Infrastructure-as-Code auf Fehlkonfigurationen prüfen kann. Die CVE-Datenbank von Trivy wird aus mehreren Quellen aggregiert, darunter NVD, GitHub Security Advisories und distributionsspezifische Advisories wie Debian- und Alpine-Security-Trackers, was eine hohe Trefferquote bei aktuellen Distributionen ergibt.

Der erste Scan eines Images mit Trivy läuft ohne vorherige Konfiguration und lädt beim ersten Aufruf automatisch die aktuelle Vulnerability-Datenbank herunter. In CI-Pipelines sollte diese Datenbank zwischengespeichert werden, um wiederholte Downloads bei jedem Build zu vermeiden, was die Scan-Zeit erheblich verkürzt.

#!/usr/bin/env bash
# First Trivy scan against a built image, with severity filtering
set -euo pipefail

# Scan for OS packages and language dependencies, only report HIGH/CRITICAL
trivy image \
  --severity HIGH,CRITICAL \
  --ignore-unfixed \
  --format table \
  myregistry.example.com/shop-api:1.4.2

# Cache the vulnerability database between CI runs
trivy image --cache-dir /opt/trivy-cache --download-db-only

3. Grype: Aufbau, Datenquellen und erster Scan

Grype von Anchore ist stärker auf reines Image Scanning und Dateisystem-Analysen fokussiert und wird häufig zusammen mit Syft eingesetzt, das die Software Bill of Materials für ein Image erzeugt, die Grype dann gegen die eigene Vulnerability-Datenbank prüft. Diese Trennung zwischen SBOM-Erzeugung und Schwachstellenprüfung ist ein architektonischer Unterschied zu Trivy, der es erlaubt, eine einmal erzeugte SBOM gegen mehrere Datenbankstände zu prüfen, ohne das Image erneut analysieren zu müssen.

Grype nutzt eine eigene aggregierte Datenbank, die ähnliche Quellen wie Trivy zusammenführt, aber in der Praxis teilweise andere Ergebnisse liefert, weil Aktualisierungszyklen und Normalisierungslogik der beiden Projekte unabhängig voneinander funktionieren. Wer beide Scanner parallel gegen dasselbe Image laufen lässt, findet regelmäßig CVEs, die nur eines der beiden Werkzeuge meldet.

#!/usr/bin/env bash
# Generate an SBOM with Syft, then scan it with Grype
set -euo pipefail

syft myregistry.example.com/shop-api:1.4.2 -o cyclonedx-json > sbom.json

grype sbom:sbom.json \
  --fail-on high \
  --only-fixed \
  -o table

4. Scan-Ergebnisse lesen und Severity einordnen

Sowohl Trivy als auch Grype klassifizieren Funde nach den Stufen `LOW`, `MEDIUM`, `HIGH` und `CRITICAL`, basierend auf dem CVSS-Score der jeweiligen Schwachstelle. Diese Einstufung ist ein sinnvoller Ausgangspunkt für Image Scanning, aber kein Ersatz für Kontextbewertung: Eine `CRITICAL`-Schwachstelle in einer Bibliothek, die im eigenen Container nie tatsächlich aufgerufen wird, hat in der Praxis eine niedrigere reale Priorität als eine `HIGH`-Schwachstelle in einer Bibliothek mit direkter Netzwerk-Exposition.

Beide Werkzeuge unterstützen einen Filter auf Schwachstellen mit bereits verfügbarem Fix, `--ignore-unfixed` bei Trivy und `--only-fixed` bei Grype. Dieser Filter ist bei Image Scanning in CI-Pipelines besonders wertvoll, weil er verhindert, dass ein Build wegen einer Schwachstelle blockiert wird, für die der Maintainer der betroffenen Bibliothek noch gar keinen Patch veröffentlicht hat. Diese Funde landen stattdessen in einer Beobachtungsliste, die regelmäßig erneut geprüft wird.

Zusätzlich zum reinen CVSS-Score liefern beide Werkzeuge oft auch den EPSS-Wert, der die tatsächliche Ausnutzungswahrscheinlichkeit einer Schwachstelle in freier Wildbahn schätzt. Für Image Scanning in großen Umgebungen mit hunderten Findings pro Tag ist dieser Wert oft aussagekräftiger als der reine Schweregrad, weil er zwischen theoretisch kritischen und praktisch tatsächlich angegriffenen Schwachstellen unterscheidet und so die Priorisierung im Team spürbar erleichtert.

5. Severity-Gates in der CI-Pipeline definieren

Ein Build, der bei jedem `LOW`-Fund fehlschlägt, wird schnell ignoriert, weil Entwickler beginnen, den fehlgeschlagenen Pipeline-Schritt routinemäßig zu überspringen. Der praxistaugliche Ansatz für Image Scanning in CI ist ein abgestuftes Gate: `CRITICAL`-Funde blockieren den Merge sofort, `HIGH`-Funde erzeugen eine Pflicht-Review-Anforderung, und `MEDIUM`/`LOW`-Funde landen in einem Dashboard zur regelmäßigen Triage, ohne den Build zu stoppen.

Beide Scanner geben über den Exit-Code zurück, ob Funde oberhalb der konfigurierten Schwelle vorliegen, was die Integration in jede CI-Plattform vereinfacht. Wichtig ist, diese Schwelle nicht statisch für alle Projekte gleich zu setzen: Ein intern genutztes Admin-Tool ohne Internetzugang verträgt ein lockereres Gate als eine öffentlich erreichbare Zahlungsschnittstelle.

#!/usr/bin/env bash
# CI gate: fail the pipeline only on CRITICAL findings with an available fix
set -euo pipefail

trivy image --severity CRITICAL --ignore-unfixed --exit-code 1 \
  --format json --output trivy-report.json \
  myregistry.example.com/payment-api:2.1.0

echo "[OK] No unfixed CRITICAL vulnerabilities found"

# Log HIGH findings separately for a review queue, without failing the build
trivy image --severity HIGH --format json --output trivy-high-report.json \
  myregistry.example.com/payment-api:2.1.0 || true

6. SBOM-Erzeugung und Nachverfolgbarkeit

Eine Software Bill of Materials listet jede Komponente eines Images auf, inklusive Versionsnummer und Lizenz, unabhängig davon, ob aktuell eine Schwachstelle bekannt ist. Für Image Scanning ist die SBOM der Ausgangspunkt: Wird morgen eine neue CVE für eine bestimmte Bibliotheksversion veröffentlicht, lässt sich anhand einer archivierten SBOM sofort feststellen, welche produktiven Images betroffen sind, ohne jedes Image erneut zu scannen.

Trivy erzeugt SBOMs direkt mit dem Flag `--format cyclonedx` oder `--format spdx-json`, Grype nutzt dafür typischerweise Syft als vorgeschalteten Schritt. Beide Formate, CycloneDX und SPDX, sind vom Großteil der nachgelagerten Werkzeuge lesbar, sodass die Wahl des Formats meist von bestehenden Compliance-Anforderungen des Unternehmens abhängt, nicht vom Scanner selbst.

#!/usr/bin/env bash
# Archive an SBOM per release, then re-check it against a fresh vulnerability database
set -euo pipefail

RELEASE_TAG="1.4.2"
syft "myregistry.example.com/shop-api:${RELEASE_TAG}" -o cyclonedx-json \
  > "sboms/shop-api-${RELEASE_TAG}.cdx.json"

# Weeks later, re-scan the archived SBOM without touching the image again
grype "sbom:sboms/shop-api-${RELEASE_TAG}.cdx.json" --only-fixed -o table

7. Umgang mit False Positives und Ignore-Listen

Kein Image Scanning-Werkzeug ist frei von Fehlklassifikationen. Eine Bibliothek kann als verwundbar markiert werden, obwohl der betroffene Code-Pfad im eigenen Image durch eine Compile-Time-Option deaktiviert wurde, oder eine CVE wurde inzwischen als "nicht anwendbar" zurückgezogen, aber die lokale Datenbank ist noch nicht aktualisiert. Für solche Fälle unterstützen beide Scanner projektbezogene Ignore-Dateien, `.trivyignore` bei Trivy und `.grype.yaml` mit einer Ignore-Sektion bei Grype.

Jeder Eintrag in einer Ignore-Datei sollte mit einer kurzen Begründung und einem Ablaufdatum versehen werden, damit die Liste nicht zur stillen Müllhalde für unbequeme Funde wird. Ohne Ablaufdatum bleiben veraltete Ausnahmen oft jahrelang bestehen, selbst nachdem sich die zugrunde liegende Einschätzung längst geändert hat.

Sinnvoll ist außerdem, die Ignore-Liste regelmäßig automatisiert gegen die aktuelle Datenbank zu validieren, statt sie nur einmalig zu pflegen. Ein einfacher geplanter Job, der prüft, ob ein ignorierter CVE inzwischen einen Fix erhalten hat, verhindert, dass Image Scanning stillschweigend eine mittlerweile behebbare Schwachstelle dauerhaft übersieht, nur weil sie vor Monaten einmal als unfixed markiert wurde.

8. Basis-Images bewusst wählen, um Scan-Rauschen zu reduzieren

Die Wahl des Basis-Images hat direkten Einfluss auf das Ergebnis von Image Scanning, oft mehr als jede nachträgliche Konfiguration des Scanners selbst. Ein volles `debian:bookworm`-Image bringt deutlich mehr Systempakete mit als ein `debian:bookworm-slim` oder gar ein Distroless-Image von Google, und jedes zusätzliche Paket ist eine potenzielle Quelle für neue CVEs. Schlanke Basis-Images reduzieren die Angriffsfläche und gleichzeitig die Menge an Findings, die überhaupt erst bewertet werden müssen.

Für Sprachen mit statisch kompilierten Binaries, etwa Go, lohnt sich der Umstieg auf ein Distroless- oder Scratch-Image, das im Idealfall gar keine Systempakete mehr enthält und damit fast keine OS-Level-Findings mehr erzeugt. Für PHP- oder Node-basierte Anwendungen ist ein vollständig paketfreies Image selten praktikabel, aber ein bewusst minimales Basis-Image reduziert die Trefferquote von Image Scanning dennoch spürbar.

# Dockerfile snippet: comparing a full base image against a slim variant
# BEFORE: full Debian image, many system packages, larger scan surface
# FROM debian:bookworm

# AFTER: slim variant, fewer packages, noticeably fewer image scanning findings
FROM debian:bookworm-slim
RUN apt-get update && apt-get install -y --no-install-recommends \
      ca-certificates \
    && rm -rf /var/lib/apt/lists/*

9. Trivy und Grype im direkten Vergleich

Beide Scanner erfüllen denselben Kernzweck, unterscheiden sich aber in Architektur, Zusatzfunktionen und Integrationstiefe. Die folgende Tabelle stellt die wichtigsten Unterschiede gegenüber.

In der Praxis ist die Kombination aus beiden Scannern nicht redundant, sondern erhöht die Erkennungsrate messbar, weil sich die Datenbankquellen nur teilweise überschneiden. Wer nur ein Budget für ein Werkzeug hat, sollte Trivy wegen der breiteren Zusatzfunktionen wie IaC-Scanning bevorzugen; wer bereits mit SBOM-basierten Compliance-Workflows arbeitet, profitiert von der klaren Trennung zwischen Syft und Grype.

10. Zusammenfassung

Image Scanning mit Trivy oder Grype schließt eine Lücke, die reines Code-Review nie abdecken kann: transitive Abhängigkeiten und Systempakete, die eigene CVEs tragen, unabhängig vom Anwendungscode. Beide Werkzeuge sind kostenlos, CI-tauglich und unterstützen abgestufte Severity-Filter, unterscheiden sich aber in Zusatzfunktionen und Datenbankquellen genug, dass eine Kombination beider Scanner regelmäßig zusätzliche Funde liefert.

Entscheidend für den produktiven Erfolg von Image Scanning ist nicht das gewählte Werkzeug allein, sondern ein durchdachtes Severity-Gate, eine gepflegte Ignore-Liste mit Ablaufdaten und die bewusste Wahl schlanker Basis-Images, die von vornherein weniger Angriffsfläche und weniger Scan-Rauschen erzeugen.

11. FAQ: Image Scanning mit Trivy und Grype