Container-Image-Scanning in CI/CD: Schwachstellen vor dem Deployment finden

1. Warum Image-Scanning fester Bestandteil der Pipeline sein muss

Ein produktives Docker-Image ist selten reiner Anwendungscode. Es enthält fast immer eine Basis-Distribution wie Debian oder Alpine, dazu Systempakete, eine Sprachlaufzeit wie PHP oder Node.js und eine lange Liste von Bibliotheken, die über einen Paketmanager installiert wurden. Jede dieser Komponenten wird unabhängig vom eigenen Team gepflegt, was bedeutet, dass neue Schwachstellen jederzeit öffentlich bekannt werden können, ohne dass sich am eigenen Anwendungscode etwas geändert hat.

Ohne systematisches Scanning bleibt die einzige Möglichkeit, solche Lücken zu entdecken, ein manuelles Nachschlagen in Sicherheits-Advisories, was in der Praxis kaum konsequent durchgehalten wird. Automatisiertes Scanning macht diesen Abgleich zu einem festen, wiederholbaren Schritt jeder Pipeline-Ausführung und stellt sicher, dass ein neues, kritisches CVE nicht erst nach Wochen oder gar nie auffällt.

2. Wie Vulnerability-Scanner ein Image analysieren

Ein Scanner wie Trivy oder Grype zerlegt ein Container-Image schichtweise und identifiziert darin installierte Pakete anhand ihrer Metadaten, etwa der Paketdatenbank von Debian oder der Lockfiles von npm und Composer. Diese Paketliste wird anschließend gegen eine oder mehrere CVE-Datenbanken abgeglichen, die bekannte Schwachstellen mit betroffenen Versionsbereichen verknüpfen.

Das Ergebnis ist eine Liste gefundener Schwachstellen samt Schweregrad, betroffenem Paket, installierter Version und, sofern vorhanden, der Version, in der die Lücke bereits behoben wurde. Diese strukturierte Ausgabe lässt sich maschinell auswerten, was Scanning erst zur automatisierbaren CI-Aufgabe macht, statt zu einer manuellen Recherche.

3. Trivy und Grype im Vergleich

Trivy von Aqua Security deckt neben Betriebssystempaketen und Anwendungsabhängigkeiten zusätzlich Fehlkonfigurationen, Secrets im Image und Lizenzprobleme ab, was es zu einem vielseitigen Werkzeug für ein einzelnes CI-Gate macht. Grype von Anchore konzentriert sich enger auf die reine Schwachstellenerkennung, gilt dafür aber als besonders präzise bei der Versionsauswertung und lässt sich gut mit Anchores SBOM-Werkzeug Syft kombinieren.

In der Praxis unterscheiden sich beide Werkzeuge weniger in der grundsätzlichen Fähigkeit als in Detailfragen wie Scan-Geschwindigkeit, Aktualität der Datenbank und der Qualität der Ausgabeformate. Viele Teams setzen bewusst beide parallel ein, weil unterschiedliche Datenbanken gelegentlich unterschiedliche Ergebnisse liefern und eine zweite Quelle blinde Flecken einer einzelnen Datenbank ausgleicht.

# GitHub Actions: Trivy-Scan als Pflicht-Gate vor dem Push in die Registry
name: container-scan
on:
  push:
    branches: [main]

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

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

      - name: Trivy Scan ausführen
        uses: aquasecurity/trivy-action@0.24.0
        with:
          image-ref: "shop-app:${{ github.sha }}"
          format: "table"
          exit-code: "1"
          severity: "CRITICAL,HIGH"
          ignore-unfixed: true

      - name: Image in Registry pushen
        if: success()
        run: docker push registry.internal/shop-app:${{ github.sha }}

4. Ein CI-Gate, das den Build bei kritischen CVEs blockiert

Ein wirksames CI-Gate bricht den Pipeline-Lauf mit einem von null verschiedenen Exit-Code ab, sobald der Scanner Schwachstellen oberhalb eines definierten Schweregrads findet. Im obigen Beispiel geschieht das über exit-code: 1 in Kombination mit severity: CRITICAL,HIGH, wodurch der nachfolgende Push-Schritt gar nicht erst ausgeführt wird und ein verwundbares Image niemals in die Registry gelangt.

Wichtig ist dabei, dass das Gate frühzeitig im Workflow sitzt, direkt nach dem Bauen des Images und vor jedem Deployment-Schritt. Ein Scan, der zwar läuft, dessen Ergebnis aber nur informativ angezeigt und nicht durchgesetzt wird, verkommt schnell zu einer ignorierten Warnung, die niemand mehr ernst nimmt, sobald sie zur Gewohnheit geworden ist.

5. Severity-Schwellenwerte sinnvoll wählen

Ein Gate, das bei jeder noch so niedrigen Schwachstelle blockiert, führt in der Praxis schnell zu Frustration, weil kaum ein realistisches Basis-Image komplett frei von niedrig eingestuften CVEs ist. Sinnvoller ist ein gestufter Ansatz, bei dem kritische und hohe Schwachstellen den Build zuverlässig stoppen, während mittlere und niedrige Funde als Warnung sichtbar gemacht, aber nicht automatisch blockiert werden.

Zusätzlich lohnt sich die Option ignore-unfixed, die Schwachstellen ausblendet, für die der Paket-Maintainer noch keinen Patch veröffentlicht hat. Ein Build an genau dieser Stelle zu blockieren, wäre unproduktiv, da das Team ohnehin nichts tun kann, außer auf ein Upstream-Fix zu warten oder das betroffene Paket manuell zu ersetzen.

6. Umgang mit Schwachstellen in Basis-Images, die man nicht selbst kontrolliert

Ein häufiges Problem sind Schwachstellen, die tief in der Basis-Distribution eines offiziellen Images stecken, etwa in einer Bibliothek, die das Betriebssystem selbst mitbringt und die niemand im eigenen Team direkt beeinflussen kann. Hier hilft es, regelmäßig auf schlankere Basis-Images umzusteigen, etwa distroless-Varianten oder Alpine-basierte Images, die von vornherein deutlich weniger installierte Pakete und damit eine kleinere Angriffsfläche mitbringen.

Für Fälle, in denen ein Fix schlicht noch nicht existiert, das Risiko aber vertretbar ist, sollte es einen dokumentierten Ausnahmeprozess geben: eine zeitlich befristete Ignore-Regel mit Begründung, verantwortlicher Person und einem Wiedervorlage-Datum, statt einer stillschweigenden, dauerhaften Unterdrückung der Warnung im Scanner.

7. SBOM als Ergänzung zum reinen Scan

Eine Software Bill of Materials, kurz SBOM, listet sämtliche in einem Image enthaltenen Komponenten samt Version auf, unabhängig davon, ob aktuell eine Schwachstelle bekannt ist. Werkzeuge wie Syft erzeugen eine solche Liste im standardisierten CycloneDX- oder SPDX-Format direkt aus dem gebauten Image heraus.

Der Wert einer SBOM zeigt sich vor allem dann, wenn eine neue Schwachstelle in einer weit verbreiteten Bibliothek öffentlich wird, wie es bei log4shell der Fall war. Statt jedes Image erneut vollständig scannen zu müssen, lässt sich anhand vorhandener SBOMs sofort abfragen, welche produktiven Images die betroffene Komponente überhaupt enthalten, was die Reaktionszeit auf solche Vorfälle drastisch verkürzt.

8. False Positives und Ausnahmen sauber verwalten

Scanner melden gelegentlich Schwachstellen, die in der konkreten Nutzung gar nicht ausnutzbar sind, etwa weil die betroffene Funktion einer Bibliothek im eigenen Code niemals aufgerufen wird. Solche False Positives pauschal zu ignorieren, ohne sie zu dokumentieren, führt langfristig dazu, dass echte Funde in der Masse untergehen.

Sowohl Trivy als auch Grype unterstützen Ignore-Dateien, in denen einzelne CVE-IDs mit Begründung ausgeschlossen werden können. Diese Dateien gehören ins Versionskontrollsystem und sollten Teil des Code-Reviews sein, damit jede Ausnahme nachvollziehbar bleibt und regelmäßig darauf geprüft wird, ob sie noch gerechtfertigt ist.

9. Scanning in der Registry versus im CI-Pipeline-Lauf

Scanning direkt in der CI-Pipeline entdeckt Schwachstellen, bevor ein Image überhaupt existiert, und verhindert damit proaktiv, dass verwundbare Images entstehen. Ein zusätzliches, periodisches Scanning bereits gepushter Images direkt in der Container-Registry deckt dagegen Schwachstellen ab, die erst nach dem ursprünglichen Build öffentlich bekannt wurden, während das Image selbst unverändert im Register liegt.

Beide Ebenen ergänzen sich sinnvoll: Das Pipeline-Gate verhindert, dass neue Lücken erst entstehen, während das Registry-Scanning bereits im Umlauf befindliche Images kontinuierlich neu bewertet und so auch nachträglich bekannt gewordene Risiken sichtbar macht, lange bevor ein betroffenes Image das nächste Mal neu deployt wird.

10. Zusammenfassung

11. FAQ: Container-Image-Scanning in CI/CD: Das Wichtigste auf einen Blick