Docker Image Scanning und Sicherheitsupdates in CI

1. Warum Image Scanning in der CI unverzichtbar ist

Docker Image Scanning ist keine optionale Ergänzung zum Sicherheitskonzept – es ist ein notwendiger Bestandteil jeder CI-Pipeline, die Container-Images für den Produktionseinsatz baut. Der Grund: Selbst ein heute sicheres Base-Image enthält morgen bekannte Schwachstellen, sobald CVEs für Pakete veröffentlicht werden, die im Image installiert sind. Ein Image, das einmal gebaut und nie wieder geprüft wurde, akkumuliert mit der Zeit Sicherheitslücken, ohne dass irgendjemand eine Warnung bekommt.

Die Realität in vielen Teams: Images werden gebaut, deployt und über Monate oder Jahre nicht neu gebaut. Jede neue CVE-Publikation, die ein im Image enthaltenes Paket betrifft, bleibt unsichtbar. Docker Image Scanning in der CI-Pipeline macht diese Lücken sichtbar – spätestens beim nächsten Build, idealerweise auch als periodischer Scan laufender Images in der Registry. Wer beide Ebenen abdeckt (Build-Zeit und Registry), hat einen vollständigen Überblick über den Schwachstellen-Status seines Container-Stacks.

2. Scanning-Tools im Überblick: Trivy, Grype und Snyk

Trivy von Aqua Security ist das bekannteste Open-Source-Tool für Docker Image Scanning. Es kann OS-Pakete, Anwendungsabhängigkeiten (Python, Ruby, Node, PHP Composer, Java Maven), Konfigurationsdateien und IaC-Dateien scannen. Trivy nutzt die NVD- und OS-Vendor-Schwachstellendatenbanken und aktualisiert sie bei jedem Aufruf automatisch. Die Integration in GitHub Actions, GitLab CI und andere CI-Systeme ist gut dokumentiert und mit wenigen Zeilen YAML erledigt.

Grype von Anchore ist eine starke Alternative mit ähnlichem Funktionsumfang. Der Hauptvorteil von Grype ist die tiefere Integration mit Syft, dem dazugehörigen SBOM-Tool: Man generiert zuerst ein SBOM mit Syft und lässt dann Grype das SBOM auf Schwachstellen prüfen. Das trennt Scanning und Inventarisierung sauber. Snyk ist ein kommerzielles Produkt mit freiem Tier für kleine Teams – es bietet über das reine Docker Image Scanning hinaus auch Autofix-Vorschläge und eine Web-UI für das Management von Schwachstellen über mehrere Projekte hinweg.

# .github/workflows/docker-security.yml — Image scanning in GitHub Actions
name: Docker Image Security Scan

on:
  push:
    branches: [main, develop]
  schedule:
    # Scan weekly even without new pushes — catch newly published CVEs
    - cron: '0 6 * * 1'

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

      - name: Build Docker image
        run: docker build -t myapp:${ { github.sha } } .

      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: myapp:${ { github.sha } }
          format: sarif
          output: trivy-results.sarif
          # Fail on HIGH and CRITICAL vulnerabilities
          severity: HIGH,CRITICAL
          # Ignore vulnerabilities without a fix (no point blocking on those)
          ignore-unfixed: true

      - name: Upload scan results to GitHub Security tab
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: trivy-results.sarif

3. Trivy in der CI-Pipeline integrieren

Trivy lässt sich als CLI-Tool, als Docker-Container oder als GitHub Action einsetzen. Für CI-Pipelines ist die GitHub Action der einfachste Einstieg; für komplexere Pipelines mit eigenem Runner eignet sich der Trivy-Container. Die wichtigste Entscheidung bei der Integration ist, an welcher Stelle im Build-Prozess das Scanning stattfindet: am besten direkt nach dem docker build-Schritt, bevor das Image in die Registry gepusht wird. So scheitert der Build, wenn kritische Schwachstellen gefunden werden, und kein unsicheres Image erreicht die Registry.

Das SARIF-Ausgabeformat von Trivy integriert sich nahtlos in GitHub Security, GitLab Security Dashboard und andere Plattformen, die SARIF verstehen. Damit werden Scan-Ergebnisse direkt im Pull-Request angezeigt und können ohne zusätzliche Tooling-Schicht von Entwicklern eingesehen werden. Für das lokale Docker Image Scanning ohne CI eignet sich trivy image imagename:tag – in wenigen Sekunden erscheint eine sortierte Tabelle mit allen gefundenen CVEs, Schweregrad, CVSS-Score und verfügbaren Fixes.

4. CVSS-Schwellenwerte und Ausnahmen definieren

Eine CI-Pipeline, die bei jedem CRITICAL-CVE den Build stoppt, wird schnell zum Hindernis, wenn ein kritisches CVE in einem transitiven Paket existiert, für das noch kein Fix verfügbar ist. Die Lösung: Differenzierte Schwellenwerte mit einer Ausnahme-Liste für CVEs, die bekannt sind, kein Fix vorhanden ist und für den konkreten Einsatzfall als akzeptables Risiko bewertet wurden. Trivy unterstützt eine .trivyignore-Datei im Projektverzeichnis, in der CVE-IDs eingetragen werden können, die beim Scan ignoriert werden sollen.

Eine sinnvolle Eskalationsstrategie für Docker Image Scanning in der CI: CRITICAL-CVEs mit verfügbarem Fix blockieren den Build. HIGH-CVEs ohne Fix erzeugen eine Warnung, blockieren aber nicht. MEDIUM und LOW werden dokumentiert, aber weder blockiert noch gewarnt. Diese Strategie verhindert, dass Builds wegen nicht behebbarer Schwachstellen dauerhaft blockiert werden, ohne dass echte Risiken unsichtbar bleiben. Die Ausnahme-Liste muss regelmäßig geprüft werden: sobald ein Fix für ein ignoriertes CVE verfügbar ist, muss der Eintrag aus der Ausnahme-Liste entfernt werden.

# .trivyignore — Document each exception with reason and review date
# Format: CVE-ID [optional comment]

# CVE-2024-12345: libssl vulnerability, no fix available for alpine 3.19 base
# Review by: 2026-06-01
CVE-2024-12345

# CVE-2024-67890: zlib integer overflow, only exploitable via crafted ZIP files
# Our application does not process untrusted ZIP files (reviewed 2026-04-15)
CVE-2024-67890

---

# trivy.yaml — Project-level Trivy configuration
severity:
  - CRITICAL
  - HIGH

# Only fail on vulnerabilities that have a fix
ignore-unfixed: true

# Skip development dependencies (they don't end up in production images)
skip-dirs:
  - node_modules/.bin
  - vendor/bin

# Output formats for different purposes
format: table   # Human-readable for local use

# Scan timeout — useful for large images with many packages
timeout: 10m0s

5. SBOM generieren und auswerten

Ein SBOM (Software Bill of Materials) ist ein vollständiges Inventar aller im Image enthaltenen Pakete, Bibliotheken und Abhängigkeiten – vergleichbar mit einem Lieferschein für Software. Docker Image Scanning und SBOM-Generierung ergänzen sich: Der Scan identifiziert aktuelle Schwachstellen, das SBOM ermöglicht es, neue CVEs zu einem beliebigen späteren Zeitpunkt gegen ein bereits existierendes Image zu prüfen, ohne das Image erneut zu bauen. Das ist besonders wertvoll, wenn ein kritischer CVE für ein Paket veröffentlicht wird und geprüft werden muss, welche der laufenden Images betroffen sind.

Das SBOM-Format SPDX und CycloneDX sind die relevanten Standards. Trivy kann SBOMs in beiden Formaten generieren. Syft von Anchore ist ein dediziertes SBOM-Tool, das tiefer in die Paketstruktur des Images einsteigt und als Ergänzung zu Trivy verwendet werden kann. SBOMs werden idealerweise zusammen mit dem Image in der Registry gespeichert – entweder als OCI-Artifact oder als separate Datei. Das ermöglicht spätere Analysen ohne Zugriff auf das Build-System und ist in manchen Compliance-Frameworks bereits als Anforderung formuliert.

6. Base-Images aktuell halten

Die meisten CVEs in Docker Images kommen aus dem Base-Image, nicht aus der eigenen Anwendung. Der schnellste Weg, den CVE-Count zu reduzieren, ist ein aktuelles Base-Image. php:8.4-fpm-alpine hat deutlich weniger installierte Pakete – und damit deutlich weniger Angriffsfläche – als php:8.4-fpm auf Debian-Basis. Alpine-Images sind bei aktiven CVE-Programmen gut gepflegt und werden bei kritischen Schwachstellen schneller aktualisiert als viele andere Distributions-Images.

Base-Images sollten niemals mit einem festen SHA-Digest im Dockerfile pinnen, ohne einen Prozess zu haben, der diese Digest-Pins regelmäßig aktualisiert. Ein gepinntes Digest-Image sieht nach mehr Kontrolle aus, ist aber ein statisches Ziel: Neue Sicherheitsupdates kommen nicht automatisch rein. Das richtige Muster ist: Tag ohne SHA im Dockerfile + automatischer Update-Prozess über Renovate oder Dependabot, der den Tag beim Erscheinen neuer Images automatisch aktualisiert und einen Pull-Request erstellt.

7. Renovate für automatische Dockerfile-Updates

Renovate ist ein Open-Source-Dependency-Update-Bot, der Dockerfiles, Compose-Dateien, GitHub Actions und viele andere Konfigurationsformate auf veraltete Versionen prüft und automatisch Pull Requests mit Updates erstellt. Für Docker Image Scanning-Workflows ist Renovate der ideale Ergänzung: Während der Scan die aktuellen Schwachstellen aufzeigt, sorgt Renovate dafür, dass Base-Images und Abhängigkeiten aktuell bleiben und neue Patches automatisch in einen Review-Prozess einfließen.

Renovate erkennt Versionsmuster in Dockerfiles automatisch: FROM php:8.4-fpm-alpine wird als versionierter Dependency erkannt und Renovate prüft, ob eine neuere Alpine-Version verfügbar ist. Die Konfiguration in renovate.json ermöglicht es, Automerge für Patch-Updates zu aktivieren (damit minimale Updates automatisch übernommen werden, ohne manuellen Review), während Minor- und Major-Updates immer einen manuellen Review erfordern. Damit reduziert sich der manuelle Aufwand für Security-Updates erheblich, ohne die Kontrolle über bedeutende Versionssprünge aufzugeben.

# renovate.json — Automated Dockerfile and Docker Compose updates
{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:best-practices"],
  "docker": {
    "enabled": true
  },
  "packageRules": [
    {
      "matchManagers": ["dockerfile", "docker-compose"],
      "matchUpdateTypes": ["patch"],
      "automerge": true,
      "automergeType": "pr",
      "addLabels": ["security", "auto-merge"]
    },
    {
      "matchManagers": ["dockerfile", "docker-compose"],
      "matchUpdateTypes": ["minor", "major"],
      "reviewers": ["team:platform"],
      "addLabels": ["security", "needs-review"]
    }
  ],
  "schedule": ["every weekend"],
  "prConcurrentLimit": 5
}

# Test Renovate configuration locally:
# npx renovate --token $GITHUB_TOKEN --dry-run=lookup owner/repo

8. Dockerfile-Härtung als erste Sicherheitslinie

Neben dem reaktiven Docker Image Scanning gibt es proaktive Maßnahmen im Dockerfile selbst, die die Angriffsfläche von Anfang an reduzieren. Der wichtigste Schritt: Container sollten nie als root-Benutzer laufen. Ein dedizierter Nicht-Root-Benutzer im Dockerfile verhindert, dass ein kompromittierter Container-Prozess direkt auf Host-Ressourcen zugreifen kann, falls eine Container-Escape-Schwachstelle ausgenutzt wird. Das USER-Statement im Dockerfile kombiniert mit dem korrekten Setzen von Dateiberechtigungen ist in wenigen Zeilen umgesetzt.

Weitere Maßnahmen: Distroless-Images oder Alpine-Minimalimages reduzieren die Anzahl installierter Pakete und damit die Scanning-Fläche drastisch. Multi-Stage-Builds stellen sicher, dass Build-Tools (Compiler, Package-Manager, Dev-Dependencies) nicht in das finale Produktions-Image gelangen. Das COPY --chown-Flag setzt Dateiberechtigungen beim Kopieren direkt korrekt, statt später RUN chown ausführen zu müssen – das spart einen Layer und ist klarer in der Intention. Zusammen mit regelmäßigem Docker Image Scanning in der CI bildet Dockerfile-Härtung eine mehrschichtige Sicherheitsstrategie.

9. Scanning-Tools im Vergleich

Die Wahl des richtigen Docker Image Scanning-Tools hängt von Anforderungen ab. Alle drei führenden Tools scannen OS-Pakete und Anwendungsabhängigkeiten, unterscheiden sich aber in Lizenz, Integrationstiefe und Zusatzfunktionen.

Für die meisten Teams ist Trivy die erste Wahl: Open Source, aktiv gepflegt, umfangreicher Scan-Umfang und hervorragende CI-Integration. Grype ist eine gleichwertige Alternative, wenn Syft bereits für SBOM-Generierung eingesetzt wird. Snyk lohnt sich, wenn das Team bereit ist, für Autofix-Vorschläge und zentrale Schwachstellen-Verwaltung zu bezahlen. Docker Scout ist für Teams attraktiv, die bereits Docker Hub und Docker Desktop intensiv nutzen und eine nahtlose Integration ohne zusätzliche Tools bevorzugen.

10. Zusammenfassung

Docker Image Scanning in der CI-Pipeline ist der Mechanismus, der verhindert, dass bekannte Schwachstellen unbemerkt in die Produktion gelangen. Trivy ist das empfohlene Tool für die meisten Teams: Open Source, einfach zu integrieren, umfangreicher Scan-Umfang inklusive SBOM-Generierung. CVSS-Schwellenwerte und eine gepflegte Ausnahme-Liste verhindern, dass der Build dauerhaft wegen nicht behebbarer Schwachstellen blockiert wird. Renovate ergänzt das Scanning mit proaktiven Updates: statt nur Schwachstellen zu melden, aktualisiert es Base-Images automatisch.

Die vollständige Strategie kombiniert reaktives Scanning (CVEs in bestehenden Images finden), proaktive Härtung (Distroless-Images, Nicht-Root-Benutzer, minimale Pakete) und automatische Updates (Renovate für Base-Images und Abhängigkeiten). SBOM-Generierung als Teil des Build-Prozesses sorgt dafür, dass neu veröffentlichte CVEs auch gegen bereits deployete Images geprüft werden können, ohne sie neu bauen zu müssen. Zusammen bilden diese drei Bausteine eine mehrschichtige Container-Sicherheitsstrategie, die mit dem Stand der Bedrohungslandschaft Schritt hält.

11. FAQ: Docker Image Scanning und Sicherheitsupdates in CI