Warum Sie Container-Images vor dem Deployment scannen sollten (und wie es geht)

Sie haben gerade ein neues Container-Image gebaut. Der Build war erfolgreich, die Tests sind grün, und das Image liegt in Ihrer Registry. Es fühlt sich bereit für die Produktion an. Aber es gibt ein Problem, das Sie nicht sehen können: Das Image könnte bekannte Sicherheitslücken enthalten, die es einem Angreifer ermöglichen, Ihren Server zu übernehmen.

Container-Images sind keine versiegelten Boxen. Jedes Image besteht aus Layern: einem Basis-Image aus dem Internet, Systembibliotheken, Laufzeitumgebungen und Ihrem eigenen Anwendungscode. Jeder Layer kann Schwachstellen enthalten. Ein Basis-Image, das letzte Woche noch sicher war, könnte heute eine kritische CVE aufweisen. Eine Bibliothek, die Sie vor drei Monaten hinzugefügt haben, könnte eine neu entdeckte Schwachstelle haben. Diese Probleme kündigen sich nicht an. Sie müssen sie aktiv prüfen.

Was ist ein Vulnerability Scan?

Ein Vulnerability Scan ist ein automatisierter Prozess, der Ihr Container-Image öffnet, jedes Paket und jede Bibliothek darin inspiziert und mit einer Datenbank bekannter Schwachstellen abgleicht. Diese Schwachstellen werden als CVEs (Common Vulnerabilities and Exposures) erfasst. Jede CVE hat eine Schweregrad-Einstufung: niedrig, mittel, hoch oder kritisch.

Eine kritische Schwachstelle könnte Remote Code Execution ermöglichen. Ein Angreifer könnte ohne Authentifizierung die Kontrolle über Ihren Server übernehmen. Ein Problem mit hohem Schweregrad könnte es jemandem erlauben, Dateien zu lesen, auf die er keinen Zugriff haben sollte. Mittel- und niedrigschwellige Probleme sind schwerer auszunutzen, erhöhen aber dennoch das Risiko, insbesondere in Kombination mit anderen Schwachstellen.

Der Scan erstellt einen Bericht: Welche Pakete betroffen sind, wie schwerwiegend das Problem ist und auf welche behobene Version Sie aktualisieren sollten.

Warum einmal scannen nicht reicht

Schwachstellendatenbanken werden täglich aktualisiert. Ständig werden neue CVEs veröffentlicht. Ein Basis-Image, das letztes Monat Ihren Scan bestanden hat, könnte jetzt eine kritische Lücke aufweisen. Eine Bibliothek, die Sie auf eine bestimmte Version festgelegt haben, könnte eine neu entdeckte Schwachstelle haben, die bei der ersten Auswahl noch nicht bekannt war.

Deshalb muss der Scan bei jedem Build des Images durchgeführt werden. Nicht nur beim ersten Build. Nicht nur, wenn Sie daran denken. Bei jedem Build. Der Scan sollte Teil Ihrer Pipeline sein, automatisiert und erzwungen.

Wo der Scan in Ihrer Pipeline platziert wird

Der Scan sitzt zwischen dem Build-Schritt und dem Promotion-Schritt. Der typische Ablauf sieht so aus:

1. Image bauen
2. Image in die Registry pushen
3. Vulnerability Scan durchführen
4. Ergebnisse gegen Ihre Richtlinie prüfen
5. Wenn der Scan bestanden wird, Image in die nächste Umgebung überführen
6. Wenn der Scan fehlschlägt, Pipeline stoppen und Image reparieren

Der Scan sollte laufen, nachdem das Image gebaut wurde, aber bevor es Staging oder Produktion erreicht. So verlassen verwundbare Images niemals die Registry.

Das folgende Flussdiagramm visualisiert diesen Entscheidungsprozess:

Hier ist ein praktisches Beispiel mit Trivy in einem GitHub Actions Workflow, der das Image scannt und die Pipeline bei jeder kritischen Schwachstelle stoppt:

scan-image:
  runs-on: ubuntu-latest
  steps:
    - name: Image aus Registry pullen
      run: docker pull my-registry/my-app:${{ github.sha }}

    - name: Trivy Vulnerability Scan durchführen
      uses: aquasecurity/trivy-action@master
      with:
        image-ref: my-registry/my-app:${{ github.sha }}
        format: table
        exit-code: 1
        severity: CRITICAL

Mit exit-code: 1 wird Trivy angewiesen, einen Exit-Code ungleich Null zurückzugeben, wenn Schwachstellen gefunden werden, was die Pipeline stoppt. severity: CRITICAL setzt die Richtlinienschwelle: Nur kritische Funde führen zu einem Abbruch. Passen Sie den Schweregrad auf CRITICAL,HIGH an, wenn Sie beide Stufen blockieren möchten.

Eine Scan-Richtlinie festlegen

Eine Scan-Richtlinie definiert, was passiert, wenn Schwachstellen gefunden werden. Sie legen die Schwellenwerte fest. Für eine öffentlich zugängliche Anwendung könnten Sie die Pipeline bei jedem kritischen oder hochgradigen Fund blockieren. Für ein internes Tool könnten Sie nur kritische Probleme blockieren und hochgradige für den nächsten Sprint protokollieren.

Der Schlüssel ist Konsistenz. Entscheiden Sie nicht pro Deployment. Definieren Sie die Richtlinie einmal, schreiben Sie sie in Ihre Pipeline-Konfiguration und lassen Sie sie automatisch laufen. Wenn die Richtlinie ein Deployment blockiert, ist das ein Signal, das Image zu reparieren, nicht die Richtlinie zu umgehen.

Verwendbare Tools

Mehrere Tools können Container-Images scannen. Sie funktionieren alle ähnlich: Sie inspizieren die Image-Layer, identifizieren Pakete und gleichen sie mit CVE-Datenbanken ab.

• Trivy - Open Source, schnell, weit verbreitet. Funktioniert gut in CI-Pipelines.
• Snyk - Kommerziell mit einem kostenlosen Tarif. Integriert sich in viele Registries und CI-Systeme.
• Grype - Open Source von Anchore. Wird oft mit Syft zur SBOM-Erstellung verwendet.
• Clair - Open Source, ursprünglich von CoreOS. Wird von vielen Registry-Diensten genutzt.
• Registry-eigene Scanner - Docker Hub, Amazon ECR und Google Artifact Registry bieten automatisches Scannen für in ihren Registries gespeicherte Images an.

Wählen Sie eines, das zu Ihrem Workflow passt. Die meisten laufen als einzelner Befehl in Ihrer Pipeline.

Was tun, wenn ein Scan fehlschlägt?

Wenn die Pipeline aufgrund einer Schwachstelle stoppt, ignorieren Sie sie nicht. Die Behebung fällt normalerweise in eine dieser Kategorien:

Basis-Image aktualisieren. Das ist die häufigste Lösung. Basis-Images wie Alpine, Ubuntu oder distroless Images veröffentlichen regelmäßig aktualisierte Versionen. Wechseln Sie zur neuesten gepatchten Version und bauen Sie neu.

Anwendungsabhängigkeiten aktualisieren. Wenn die Schwachstelle in einer Bibliothek liegt, die Ihr Code verwendet, aktualisieren Sie die Abhängigkeit in Ihrem Quellcode und bauen Sie das Image neu.

Nicht benötigte Tools entfernen. Manchmal stammen Schwachstellen von Tools, die versehentlich im Image verblieben sind: Debugger, Compiler, Paketmanager. Diese werden zur Laufzeit nicht benötigt. Multi-Stage-Builds lösen dieses Problem, indem sie nur die endgültigen Laufzeitartefakte im Produktions-Image behalten.

Nach der Behebung bauen Sie das Image neu und führen den Scan erneut durch. Wiederholen Sie dies, bis das Image den Scan besteht.

Was Vulnerability Scanning nicht ist

Scannen ist kein Ersatz für andere Sicherheitspraktiken. Es deckt keine Penetrationstests, Zugriffskontrollen, Netzwerksicherheit oder Laufzeitüberwachung ab. Aber es ist eine kostengünstige und effektive Verteidigungsschicht, die automatisch läuft. Ohne sie können kritische Schwachstellen in die Produktion gelangen, ohne dass jemand sie bemerkt.

Praktische Checkliste

• Fügen Sie einen Vulnerability-Scan-Schritt nach dem Image-Build in Ihrer CI-Pipeline hinzu
• Definieren Sie eine Scan-Richtlinie mit klaren Schwellenwerten (z. B. Blockieren bei kritisch und hoch)
• Konfigurieren Sie die Pipeline so, dass sie bei Richtlinienverstößen stoppt
• Verwenden Sie Multi-Stage-Builds, um die Angriffsfläche Ihrer Images zu reduzieren
• Planen Sie regelmäßige Updates für Ihre Basis-Images und Abhängigkeiten ein
• Überprüfen Sie Scan-Berichte regelmäßig, auch für bestandene Builds

Die konkrete Erkenntnis

Ein Container-Image, das nicht gescannt wurde, ist ein unbekanntes Risiko. Fügen Sie noch heute Vulnerability Scanning zu Ihrer Pipeline hinzu. Wählen Sie ein Tool, legen Sie eine Richtlinie fest und lassen Sie die Automatisierung die Probleme abfangen, bevor sie die Produktion erreichen. Die Einrichtung dauert nur wenige Minuten und erspart Ihnen, eine kritische CVE zu entdecken, nachdem ein Angreifer sie bereits gefunden hat.