Container Image Scanning: Trivy, Grype und Snyk im Praxisvergleich

TL;DR

• Container Images enthalten oft Dutzende bekannter Schwachstellen (CVEs) in OS-Paketen und Bibliotheken -- ohne Scanning bleibt das unsichtbar.
• Trivy ist der beste Einstieg: schnell, Open Source, scannt Images, Filesysteme, IaC und Kubernetes-Manifeste in einem Tool.
• Grype von Anchore bietet eine schlanke Alternative mit besonders guter SBOM-Integration via Syft.
• Snyk ergaenzt Image Scanning um Code-Analyse, Dependency Scanning und automatische Fix-PRs -- allerdings als kommerzielles Produkt.
• Der groesste Hebel liegt in der CI/CD-Integration: Scanner als Pipeline-Gate, das unsichere Images vor dem Registry-Push stoppt.

Warum Container Image Scanning nicht optional ist

Ein typisches Container Image basiert auf einem Base Image (z.B. debian:bookworm-slim), installiert OS-Pakete, kopiert Anwendungscode und zieht Abhaengigkeiten nach. Jede dieser Schichten kann bekannte Schwachstellen enthalten.

Das Problem ist nicht theoretisch. Die durchschnittliche node:18-basierte Anwendung enthaelt laut Snyk-Reports ueber 40 bekannte CVEs, davon mehrere mit CVSS-Score ueber 7.0. Viele davon sind nicht direkt exploitbar, aber einige sind es -- und genau die muss man finden.

Scanning allein reicht natuerlich nicht. Es ist ein Baustein in einer breiteren Security-Strategie, die auch Runtime Security und Network Policies umfasst. Aber ohne Scanning fehlt die Grundlage: Man weiss schlicht nicht, was man deployt.

Die drei Tools im Ueberblick

Trivy

Trivy (von Aqua Security) ist ein Open-Source-Scanner, der sich als De-facto-Standard fuer Container Image Scanning etabliert hat. Er scannt nicht nur Images, sondern auch Dateisysteme, Git-Repos, Kubernetes-Manifeste und Terraform-Dateien.

Staerken:

• Einziges Binary, keine Datenbank-Infrastruktur noetig
• Vulnerability DB wird beim ersten Scan heruntergeladen und lokal gecacht
• Unterstuetzt OS-Pakete (Debian, Alpine, RHEL) und App-Abhaengigkeiten (npm, pip, Go, Java, Rust)
• Kann auch Fehlkonfigurationen in Dockerfiles und K8s-Manifesten finden
• SBOM-Generierung (CycloneDX, SPDX)

Schwaechsten:

• Keine automatischen Fix-Vorschlaege
• Kein zentrales Dashboard (dafuer gibt es Aqua Platform, kommerziell)
• False Positives bei Language-spezifischen Paketen hoeher als bei Snyk

Grype

Grype ist der Scanner von Anchore und arbeitet eng mit Syft zusammen, dem SBOM-Generator derselben Firma. Die Architektur ist bewusst modular: Syft erzeugt eine Software Bill of Materials, Grype prueft sie gegen die Vulnerability Database.

Staerken:

• Saubere Trennung von SBOM-Generierung und Vulnerability Matching
• Sehr schnell bei wiederholten Scans (SBOM wird gecacht)
• Gute Policy-Engine ueber Anchore Enterprise
• Weniger False Positives als Trivy bei OS-Paketen

Schwaechen:

• Kein IaC-Scanning (nur Images und Filesysteme)
• Kleinere Community als Trivy
• Enterprise-Features nur kommerziell

Snyk

Snyk ist eine kommerzielle Plattform, die weit ueber Image Scanning hinausgeht. Sie scannt Code (SAST), Open-Source-Abhaengigkeiten (SCA), Container Images und IaC. Der Alleinstellungsmerkmal: automatische Fix-Pull-Requests.

Staerken:

• Automatische Fix-PRs fuer verwundbare Abhaengigkeiten
• Tiefe IDE-Integration (VS Code, IntelliJ)
• Umfassende Vulnerability Database mit Exploit-Maturity-Scoring
• Gutes Dashboard und Reporting fuer Management
• Kostenloser Tier fuer Einzelentwickler

Schwaechen:

• Kommerziell, Kosten skalieren mit Team-Groesse
• Image Scanning weniger tief als Trivy bei OS-Level-Paketen
• Vendor Lock-in bei der Plattform

Vergleichstabelle

CI/CD-Integration: Scanner als Pipeline-Gate

Der groesste Nutzen entsteht, wenn Scanning automatisch bei jedem Image Build laeuft. Das Ziel: Kein Image mit kritischen CVEs erreicht die Registry.

GitLab CI mit Trivy

# .gitlab-ci.yml
stages:
  - build
  - scan
  - push

variables:
  IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA

build-image:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  script:
    - docker build -t $IMAGE_TAG .
    - docker save $IMAGE_TAG -o image.tar
  artifacts:
    paths:
      - image.tar
    expire_in: 1 hour

trivy-scan:
  stage: scan
  image:
    name: aquasec/trivy:0.49.0
    entrypoint: [""]
  script:
    # Vulnerability DB nur einmal pro Tag laden
    - trivy image --download-db-only --cache-dir /tmp/trivy-cache
    # Image aus Tarball scannen
    - trivy image --input image.tar
        --severity HIGH,CRITICAL
        --exit-code 1
        --format table
        --cache-dir /tmp/trivy-cache
    # Zusaetzlich SBOM generieren
    - trivy image --input image.tar
        --format cyclonedx
        --output sbom.json
        --cache-dir /tmp/trivy-cache
  artifacts:
    paths:
      - sbom.json
    expire_in: 30 days
  allow_failure: false

push-image:
  stage: push
  image: docker:24
  services:
    - docker:24-dind
  script:
    - docker load -i image.tar
    - docker push $IMAGE_TAG
  only:
    - main

Wichtige Details: --exit-code 1 bricht die Pipeline ab, wenn HIGH oder CRITICAL CVEs gefunden werden. Die SBOM wird als Artefakt gespeichert -- das ist zunehmend relevant fuer Compliance-Anforderungen und Software Supply Chain Security. Mehr dazu unter Kubernetes Supply Chain Security.

GitHub Actions mit Grype

# .github/workflows/scan.yml
name: Container Security Scan
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build Image
        run: docker build -t app:${{ github.sha }} .

      - name: Generate SBOM with Syft
        uses: anchore/sbom-action@v0
        with:
          image: app:${{ github.sha }}
          format: spdx-json
          output-file: sbom.spdx.json

      - name: Scan with Grype
        uses: anchore/scan-action@v4
        id: scan
        with:
          image: app:${{ github.sha }}
          fail-build: true
          severity-cutoff: high
          output-format: sarif

      - name: Upload SARIF to GitHub Security
        uses: github/codeql-action/upload-sarif@v3
        if: always()
        with:
          sarif_file: ${{ steps.scan.outputs.sarif }}

Der Vorteil bei Grype: Die SBOM wird separat mit Syft erzeugt und kann unabhaengig archiviert werden. Das SARIF-Format integriert sich direkt in GitHub Security Alerts.

Registry Scanning: Kontinuierlich statt einmalig

Ein Image, das beim Build sauber war, kann eine Woche spaeter verwundbar sein -- weil neue CVEs veroeffentlicht wurden. Deshalb braucht man zusaetzlich zum Build-Time-Scan ein kontinuierliches Registry Scanning.

Optionen:

• Harbor (Open Source Registry) hat Trivy direkt integriert und scannt Images automatisch bei Push und periodisch.
• AWS ECR bietet nativen Scan (Basic und Enhanced via Inspector).
• Trivy-Operator im Kubernetes-Cluster scannt alle laufenden Images und erstellt VulnerabilityReport CRDs.

Der Trivy-Operator ist besonders nuetzlich, weil er direkt im Cluster laeuft und Reports als Kubernetes-Ressourcen bereitstellt:

# Trivy Operator installieren
helm install trivy-operator aquasecurity/trivy-operator \
  --namespace trivy-system \
  --create-namespace \
  --set trivy.severity="HIGH,CRITICAL" \
  --set operator.scanJobsConcurrentLimit=3

# Vulnerability Reports abfragen
kubectl get vulnerabilityreports -A \
  -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,CRITICAL:.report.summary.criticalCount,HIGH:.report.summary.highCount'

Admission Controller: Letzte Verteidigungslinie

Selbst mit CI/CD-Scanning kann es passieren, dass jemand ein ungescanntes Image manuell deployt. Ein Admission Controller im Cluster verhindert das.

Gaengige Optionen sind Kyverno und OPA Gatekeeper. Hier ein Beispiel mit Kyverno, das nur signierte und gescannte Images zulasst:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-vulnerability-scan
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    - name: check-vulnerability-scan
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - "registry.example.com/*"
          attestors:
            - count: 1
              entries:
                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                      <cosign-public-key>
                      -----END PUBLIC KEY-----
          attestations:
            - type: https://trivy.dev/scan/v1
              conditions:
                - all:
                    - key: "{{ criticalCount }}"
                      operator: LessThanOrEquals
                      value: "0"
                    - key: "{{ highCount }}"
                      operator: LessThanOrEquals
                      value: "5"

Diese Policy stellt sicher: Kein Pod mit einem Image, das nicht signiert wurde oder kritische CVEs enthaelt, kann im Cluster starten. Das ist Defense in Depth -- selbst wenn die CI/CD-Pipeline umgangen wird.

Fuer eine breitere Betrachtung von Policy Enforcement und Compliance Automation lohnt sich der Blick auf Kubernetes Compliance Automation.

Sinnvolle Schwellenwerte definieren

Ein haeufiger Fehler: Alle CVEs gleich behandeln. In der Praxis braucht man abgestufte Regeln.

Wichtig ist auch der Kontext: Eine CVE in libssl ist kritischer als eine in einer Testbibliothek, die nur im Build-Container vorkommt. Trivy und Grype koennen nicht automatisch zwischen erreichbarem und nicht-erreichbarem Code unterscheiden -- hier braucht man manuelles Triage.

Base Images haerten

Scanning ist reaktiv. Proaktiv senkt man die Angriffsflaeche, indem man schlanke Base Images verwendet:

Distroless und Scratch Images eliminieren fast alle OS-Level-CVEs. Fuer Go- und Rust-Anwendungen mit statisch gelinkten Binaries ist scratch ideal. Fuer Python und Node.js sind Distroless oder Alpine die pragmatischste Wahl.

False Positives managen

Jeder Scanner produziert False Positives -- CVEs, die technisch vorhanden, aber im Kontext nicht exploitbar sind. Trivy unterstuetzt .trivyignore-Dateien:

# .trivyignore
# CVE ist in unserem Kontext nicht erreichbar, da wir den betroffenen
# Code-Pfad nicht nutzen. Reviewed von: security@example.com, 2026-01-15
CVE-2024-12345

# Wird im naechsten Base-Image-Update gefixt (geplant: 2026-02-28)
CVE-2025-67890 exp:2026-02-28

Grype bietet aehnliche Funktionalitaet ueber Ignore-Rules in der Konfiguration. Snyk verwaltet Suppressions zentral in der Web-UI.

Wichtig: Jede Suppression sollte dokumentiert sein (wer, wann, warum) und ein Ablaufdatum haben. Sonst sammeln sich ueber die Monate hunderte ignorierter CVEs an, die niemand mehr reviewt.

Metriken, die tatsaechlich zaehlen

Statt Vanity-Metriken wie "Anzahl gescannter Images" sollte man folgende KPIs tracken:

• Mean Time to Remediate (MTTR) fuer Critical/High CVEs -- wie schnell werden gefundene Schwachstellen behoben?
• Scan Coverage -- Anteil der Images in der Registry, die in den letzten 7 Tagen gescannt wurden.
• Policy Violation Rate -- wie oft schlaegt das CI/CD-Gate an? Steigt die Rate, stimmt etwas im Entwicklungsprozess nicht.
• False Positive Rate -- wie viele Suppressions gibt es? Ein hoher Wert deutet auf schlechte Scanner-Konfiguration hin.

Empfehlung nach Team-Groesse

Einzelentwickler oder kleines Team (1-5 Personen): Trivy reicht vollstaendig. Installieren Sie es lokal und in die CI/CD-Pipeline. Kein Budget noetig.

Mittleres Team (5-20 Personen): Trivy oder Grype fuer Scanning, ergaenzt um den Trivy-Operator im Cluster und Harbor als Registry mit integriertem Scanning. Optional Snyk Free Tier fuer Dependency Scanning.

Groesseres Team oder reguliertes Umfeld (20+ Personen): Snyk oder Aqua Platform fuer zentrales Management, Reporting und automatische Remediation. Dazu Kyverno oder OPA Gatekeeper als Admission Controller. SBOM-Generierung und -Archivierung fuer Audit-Zwecke.

Unabhaengig von der Team-Groesse gilt: Scanning ohne Remediation-Prozess ist Verschwendung. Die Ergebnisse muessen in ein Ticketsystem fliessen, und es braucht klare SLAs fuer die Behebung. Fuer eine umfassendere Security-Strategie, die ueber Scanning hinausgeht, lohnt sich der Artikel zu Kubernetes Security Automation mit SOAR.

Fazit

Container Image Scanning ist kein Hexenwerk. Mit Trivy hat man in 30 Minuten einen funktionierenden Scanner in der CI/CD-Pipeline. Der schwierigere Teil ist die Organisation: Schwellenwerte definieren, Remediation-Prozesse etablieren, False Positives managen und das Team mitnehmen.

Starten Sie mit Build-Time-Scanning in einer einzelnen Pipeline. Erweitern Sie dann auf Registry Scanning und schliesslich auf Admission Controller. Dieser schrittweise Ansatz vermeidet Ueberforderung und liefert in jeder Phase messbaren Nutzen.

Falls Sie Unterstuetzung beim Aufbau einer durchgaengigen Container Security Pipeline brauchen -- von der Tool-Auswahl bis zur Kyverno-Policy -- sprechen Sie uns an unter /kontakt.