Container Security Scanning: Von der Erkennung bis zum Deployment

Container Security Scanning erkennt Schwachstellen, Fehlkonfigurationen und Secrets in container images und Runtime-Umgebungen. Dieser Artikel erklärt die Funktionsweise, die relevanten Prüfobjekte und die Integration über den gesamten Container-Lebenszyklus hinweg.

Definition von Container Security Scanning

Container Security Scanning ist ein automatisierter Prozess, der container images und laufende Container analysiert, um Schwachstellen, Fehlkonfigurationen und Bedrohungen bereits vor dem Deployment zu erkennen.

Containerisierte Umgebungen bringen Risiken mit sich, für die klassische Scanner nie ausgelegt waren. Ein einziges Image bündelt Anwendungscode, Bibliotheken von Drittanbietern und OS-Komponenten in einem Artefakt. Eine Schwachstelle in einer einzelnen Ebene wird damit zur Schwachstelle im gesamten Image. Container sind zudem bewusst kurzlebig und starten und stoppen fortlaufend. Ein Scan, der nur einmal zum Build-Zeitpunkt läuft, übersieht deshalb Bedrohungen, die erst nach dem Deployment auftreten. Registries und Orchestrierungsplattformen wie Kubernetes bringen eine eigene Konfigurationsfläche mit und eröffnen Angreifern zusätzliche Wege, sobald das Scanning nicht über das Image selbst hinausreicht.

Aus diesem Grund beruhten die Cloud-Angriffe des Jahres 2025 meist auf lange bestehenden Schwachstellen, offengelegten Secrets und Fehlkonfigurationen statt auf neuen Angriffstechniken. Ein Scanning, das den gesamten Lebenszyklus abdeckt und nicht nur das Image, schließt genau die Einstiegspunkte, auf die Angreifer am häufigsten setzen.

Erkennungsbereiche von Container Scanning

Container Scanning untersucht mehrere klar abgegrenzte Risikokategorien, die jeweils an einem anderen Punkt des Container-Lebenszyklus entstehen. Wer weiß, was das Scanning abdeckt, kann besser einschätzen, ob die eingesetzten Tools die tatsächliche Angriffsfläche adressieren. Die folgende Übersicht zeigt die verschiedenen Erkennungsarten.

Wer die Erkennungsbereiche kennt, kommt zur nächsten Frage: Wie leisten Scanner diese Arbeit über den gesamten Container-Lebenszyklus hinweg?

Funktionsweise von Container Scanning

Container Scanning arbeitet über mehrere klar getrennte Ebenen, die jeweils einen anderen Punkt im Leben eines Containers adressieren. Zusammen bilden diese Ebenen eine Verteidigung, die von der ersten Zeile eines Dockerfiles bis zum Container in Produktion reicht.

Statisches Image-Scanning

Das statische Image-Scanning analysiert die Ebenen eines container images vor dem Deployment. Es zerlegt das Image in seine Bestandteile – Base-OS, Anwendungscode und dependencies – und gleicht jeden Teil mit bekannten Schwachstellendatenbanken ab. Weil diese Analyse vor dem Start des Images stattfindet, erkennt sie Probleme wie veraltete Pakete oder eingebettete Secrets zum frühestmöglichen Zeitpunkt.

Registry-Scanning

Das Registry-Scanning prüft Images im Ruhezustand in der container registry und setzt Pull-Richtlinien durch, die anfällige oder nicht konforme Images vom Weg in die Produktion abhalten. Es wirkt als Kontrollpunkt zwischen Build und Deployment und fängt Images ab, die frühere Scans passiert haben, nun aber wegen neu offengelegter Schwachstellen markiert sind.

CI/CD-Pipeline-Scanning

Wer das Scanning direkt in die CI/CD-Pipeline integriert, verankert Sicherheitsprüfungen im Build-Prozess selbst. Eine Fail-Fast-Richtlinie stoppt einen Build, sobald eine kritische Schwachstelle erkannt wird, und verhindert, dass riskante Images weiter durch die Pipeline wandern. So lassen sich Probleme früh und schnell im Sicherheitsablauf beseitigen.

Runtime-Scanning

Das Runtime-Scanning überwacht Container während der Ausführung und beobachtet System-Calls, Prozesse und Netzwerkverhalten auf Kompromittierungen, die statische Scans vor dem Deployment nicht erfassen. Ein Container, der jede Prüfung besteht, kann nach dem Deployment dennoch kompromittiert werden – durch einen zero-day, missbrauchte Zugangsdaten oder einen Angreifer, der von einer anderen Ressource aus vordringt. Kombiniert man diese Runtime-Transparenz mit dem breiteren Cloud-Kontext, wird aus einem isolierten Alarm ein priorisierter, umsetzbarer Fund.

Praxisbeispiel: Wiz Research fand CVE-2024-0132, eine Container-Escape-Schwachstelle im NVIDIA Container Toolkit. Sie erlaubte einem schädlichen container image den Zugriff auf das Root-Dateisystem des Hosts. Ein kontinuierliches vulnerability management mit Praktiken wie dem Runtime-Scanning half Wiz, solche Probleme zu verhindern, indem Container konsequent überprüft und analysiert wurden.

SBOM-Erstellung und Dependency-Mapping

Ein software bill of materials (SBOM) erstellt ein vollständiges Inventar jeder Komponente, Bibliothek und dependency in einem container image. Dieses Inventar wird in dem Moment entscheidend, in dem eine neue Schwachstelle offengelegt wird. Als Log4Shell bekannt wurde, konnten Teams mit einem vorhandenen SBOM sofort abfragen, welche Images die betroffene Bibliothek enthielten, und die Behebung priorisieren. Teams ohne SBOM mussten diesen Kontext von Grund auf neu aufbauen und brauchten oft Tage, um ihre tatsächliche Angriffsfläche zu bestimmen.

Jede dieser Ebenen spielt in einer anderen Entwicklungsphase eine Rolle. Daraus ergibt sich die Frage, wie sie sich auf den realen Workflow vom ersten Commit bis zum laufenden Container in Produktion abbilden.

Container Scanning über den Entwicklungslebenszyklus

Container Scanning verteilt Prüfungen über die Phasen Build, Registry, Deployment und Runtime. Jede Phase erkennt andere Risikokategorien genau dort, wo ihre Behebung am günstigsten ist.

Build-Phase: Dockerfile-Scanning und Auswahl des Base Image

In der Build-Phase untersucht das Scanning das Dockerfile und das gewählte Base Image als Ausgangspunkt. Ohne diese Prüfung wird ein anfälliges Base Image aus einer öffentlichen Registry zur Grundlage jedes darauf aufbauenden Images und verankert das Risiko, bevor eine einzige Zeile Anwendungscode geschrieben ist. Ein minimales, gut gepflegtes Base Image und ein frühes Scanning des container image im Build-Prozess verhindern, dass sich dieses vererbte Risiko nach unten fortsetzt.

Registry-Phase: Durchsetzung von Richtlinien, bevor Images in die Produktion gelangen

Sobald ein Image gebaut ist, landet es in einer Registry, wo die Durchsetzung von Richtlinien entscheidet, ob es weitergehen darf. Ohne Durchsetzung an dieser Stelle kann ein Image mit einer bekannten kritischen Schwachstelle in der Registry verbleiben und dennoch von jedem Team mit Zugriff in ein Produktions-Deployment gezogen werden. Die Durchsetzung von Richtlinien wirkt hier als Kontrollpunkt, der Images abfängt, die früher übersehen oder durch neu veröffentlichte CVEs markiert wurden.

Deploy-Phase: Prüfungen mit admission controls vor dem Deployment in Kubernetes

Beim Deployment bewerten admission controllers in Kubernetes, ob ein eingehendes Image die Sicherheitsanforderungen erfüllt, bevor es ausgeführt werden darf. Ohne admission controls lässt sich ein nicht konformes Image – etwa ohne erforderliche Labels oder mit überhöhten Berechtigungen – ohne letzte Prüfung direkt in einen laufenden Cluster deployen.

Runtime-Phase: kontinuierliche Verhaltensüberwachung laufender Container

Läuft ein Container erst einmal, überwacht die kontinuierliche Verhaltensüberwachung Aktivitäten, die von erwarteten Mustern abweichen – etwa unerwartete Netzwerkverbindungen oder unautorisierte Dateiänderungen. Eine Schwachstelle, die zum Build-Zeitpunkt unbekannt war, oder Zugangsdaten, die nach dem Deployment kompromittiert werden, werden erst in dieser Phase sichtbar.

Genau hier bringt das agentless Runtime-Scanning den größten Nutzen. Wiz scannt laufende Container, ohne auf jedem Workload einen Agenten zu installieren, und liefert so kontinuierliche Runtime-Transparenz. Zugleich vermeidet dieser Ansatz den Betriebsaufwand und die Performance-Einbußen, die agent-based Ansätze mit sich bringen.

Verteilt sich das Scanning über all diese Phasen, treten die Vorteile klarer hervor, sobald sichtbar wird, wie sie sich über den Lebenszyklus summieren.

Vorteile von Container Security Scanning

Container Scanning über den gesamten Lebenszyklus bringt Vorteile, die sich vom Build bis zur Runtime summieren.

1. Frühe Erkennung von Schwachstellen

Schwachstellen bereits in der Build-Phase zu erkennen, verhindert, dass sie überhaupt in die Produktion gelangen. Dieser Shift-Left-Ansatz (Vorverlagerung der Sicherheit in den Entwicklungsprozess) legt Probleme offen, solange sie am einfachsten zu beheben sind – bevor Code zusammengeführt, deployt und von anderen Teams weiterverwendet wird.

2. Geringere Angriffsfläche in Kubernetes

Kubernetes-Manifeste auf Fehlkonfigurationen zu prüfen – etwa zu freizügige role-based access control (RBAC), offengelegte Dashboards oder Container mit unnötigen Berechtigungen – reduziert die Wege für lateral movement. Ein fehlkonfiguriertes Manifest, das einem Workload Cluster-Admin-Berechtigungen gewährt, kann etwa einen einzelnen kompromittierten Container in einen Brückenkopf für den gesamten Cluster verwandeln. Wer solche Probleme vor dem Deployment erkennt, schließt diesen Weg, bevor er entsteht.

3. Compliance mit Sicherheitsstandards

Automatisiertes Compliance-Scanning gleicht Container-Konfigurationen mit Frameworks wie den CIS Benchmarks, PCI DSS, SOC 2 und NIST ab und legt Lücken offen, bevor sie ein Audit betreffen. Wiz prüft gegen mehr als 100 Frameworks, darunter HIPAA und GDPR, sodass das Sicherheitsteam Compliance-Lücken kontinuierlich erkennt und behebt, statt kurz vor einer Audit-Frist in Hektik zu verfallen.

4. Schnellere CI/CD-Pipelines

Das Scanning in CI/CD einzubetten, scheint Builds zunächst zu verlangsamen, doch mit der Zeit gilt meist das Gegenteil. Probleme automatisch und früh zu erkennen, bedeutet weniger späte Rollbacks, weniger Notfall-Patches und weniger manuelles Hin und Her zwischen Sicherheits- und Entwicklungsteams. All das bremst Pipelines weit stärker als ein automatisierter Scan.

Diese Vorteile hängen davon ab, dass das Scanning wie beabsichtigt funktioniert. Damit rücken einige Herausforderungen in den Blick, die Teams von vornherein einplanen sollten.

Herausforderungen beim Container Scanning

Container Scanning bringt echten Nutzen, doch eine gute Umsetzung ist mit Reibungspunkten verbunden, die sich vorab einplanen lassen. Im Folgenden stehen die häufigsten Herausforderungen beim Scanning.

Alert fatigue durch eine hohe Menge an CVE-Ausgaben

Ein einzelner Scan kann Hunderte von CVEs zurückgeben, von denen viele kaum ein reales Risiko für die Umgebung darstellen. Ohne eine Möglichkeit, diese Menge zu filtern und zu priorisieren, stumpfen Sicherheitsteams schnell gegenüber Alarmen ab. Damit steigt das Risiko, dass ein wirklich kritischer Fund im Alarmrauschen untergeht.

Vererbtes Risiko aus Base Images

Jede Schwachstelle in einem Base Image wird zur Schwachstelle in jedem darauf aufbauenden Image – oft ohne dass das nachgelagerte Team es bemerkt. Dieses vererbte Risiko kann über Dutzende Images bestehen bleiben, wenn das Base Image selbst nicht regelmäßig aktualisiert und erneut gescannt wird.

Kurzlebige Container, die punktuellem Scanning entgehen

Container in modernen Umgebungen sind oft kurzlebig, starten für eine Aufgabe und beenden sich kurz darauf. Ein Scan, der nur zu einem einzigen Zeitpunkt läuft, kann den gesamten Lebenszyklus eines Containers verpassen und hinterlässt eine Transparenzlücke bei Workloads, die nur Minuten statt Tage existieren.

Priorisierung ohne Runtime-Kontext

Ein CVSS-Wert allein sagt aus, wie schwerwiegend eine Schwachstelle theoretisch sein könnte, aber nicht, ob sie in der jeweiligen Umgebung tatsächlich ausnutzbar ist. Eine kritische Schwachstelle in einem Container ohne Netzwerkexponierung birgt weit weniger Risiko als eine mittelschwere in einem Container mit direktem Weg zu sensiblen Daten. Ein CVSS-Wert allein kann diesen Unterschied nicht abbilden.

Integrität der Scanner-Supply-Chain

Die Scanning-Tools selbst stützen sich auf Schwachstellendatenbanken und Signatur-Feeds, die aktuell und vertrauenswürdig bleiben müssen. Ein Scanner mit einer veralteten Datenbank kann neu offengelegte Schwachstellen übersehen, während ein kompromittierter Feed theoretisch false positives im großen Maßstab einschleusen könnte.

Diese Herausforderungen weisen auf eine Reihe von Praktiken hin, mit denen Teams einen beständigeren Nutzen aus dem Container Scanning ziehen.

Best Practices für Container Scanning

Die folgenden Praktiken helfen Teams, Container Scanning von einer punktuellen Prüfung in einen durchgängigen Schutz über den gesamten Lebenszyklus zu verwandeln.

1. Minimale Base Images nutzen, um die vererbte CVE-Fläche zu reduzieren

Ein distroless oder Alpine-basiertes Image statt eines vollständigen Betriebssystem-Images reduziert die Zahl der Pakete und damit die Zahl möglicher Schwachstellen von Anfang an deutlich. Ein überladenes Base Image bedeutet, CVEs in Paketen zu erben, die die Anwendung nie nutzt.

2. Scanning in CI/CD integrieren und Builds bei kritischen Funden abbrechen

Das Scanning in die CI/CD-Pipeline einzubetten und so zu konfigurieren, dass Builds bei kritischen Schwachstellen abbrechen, stoppt riskante Images, bevor sie eine Registry erreichen. Ohne diesen Kontrollpunkt wird ein kritischer Fund womöglich erst sichtbar, nachdem das Image bereits in mehrere Umgebungen gezogen wurde.

Die folgende GitLab-CI-Konfiguration zeigt diesen Kontrollpunkt in der Praxis: Die Scan-Stufe bricht die Pipeline ab, sobald Trivy kritische Schwachstellen erkennt, und verhindert so, dass die Deploy-Stufe läuft.

# Sample integration of a security scanner in GitLab CI
stages:
  - build
  - scan
  - deploy

build:
  stage: build
  script:
    - docker build -t my-image .

security_scan:
  stage: scan
  script:
    - trivy image --exit-code 1 --severity CRITICAL my-image

deploy:
  stage: deploy
  script:
    - docker push my-repo/my-image:latest

3. Nicht konforme Images mit admission controls blockieren

In Kubernetes wirken admission controls als letzter Kontrollpunkt und blockieren ungescannte oder richtlinienwidrige Images vor dem Deployment. Ohne diese Durchsetzung kann ein Image, das frühere Prüfungen umgangen hat – ob durch menschliches Versehen oder eine Prozesslücke –, dennoch in einen laufenden Cluster gelangen.

4. SBOMs für Produktions-Images erstellen und pflegen

Ein aktuelles SBOM für jedes Produktions-Image gibt dem Team eine sofortige Antwort, sobald eine neue Schwachstelle in einer weit verbreiteten Bibliothek offengelegt wird. Ohne SBOM müssen Teams manuell in Images suchen, um die Angriffsfläche zu bestimmen – oft unter Zeitdruck.

5. Funde nach Runtime-Kontext priorisieren, nicht allein nach dem CVSS-Wert

Den Runtime-Kontext zur Priorisierung von Schwachstellen zu nutzen – etwa ob ein Container aus dem Internet erreichbar ist oder Zugriff auf sensible Daten hat – lenkt den Behebungsaufwand auf die wichtigsten Probleme. Wer sich allein auf CVSS-Werte stützt, verbringt womöglich Tage mit einer theoretisch kritischen Schwachstelle, während ein leichter ausnutzbares mittelschweres Problem ungelöst bleibt.

Der folgende Pseudocode zeigt dies in der Praxis: Die Ausnutzbarkeit einer Schwachstelle und der Zugriff auf sensible Daten bestimmen ihre Priorität, nicht allein die CVSS-Schwerebewertung.

# Pseudocode for prioritizing vulnerabilities by runtime context
for vulnerability in scan_results:
    if is_exploitable(environment, vulnerability) and has_sensitive_access(environment):
        raise_alert(vulnerability)
    elif is_exploitable(environment, vulnerability):
        schedule_for_remediation(vulnerability)
    else:
        log_for_review(vulnerability)

6. Kontinuierlich zur Runtime scannen, nicht nur zum Build-Zeitpunkt

Das Scanning bis in die Runtime auszuweiten, erkennt Bedrohungen, die nach dem Deployment auftreten – darunter neu offengelegte Schwachstellen und Verhaltensanomalien, die auf eine Kompromittierung hindeuten. Ein Ansatz, der nur zum Build-Zeitpunkt greift, lässt die gesamte Produktionslebensdauer eines Containers unüberwacht.

7. Niemals Secrets in Image-Ebenen speichern

Secrets wie API-Schlüssel oder Passwörter in Image-Ebenen zu speichern, macht sie selbst dann wiederherstellbar, wenn eine spätere Ebene die Datei löscht, da frühere Ebenen Teil der Image-Historie bleiben. Ein dedizierter Secrets-Manager hält Zugangsdaten vollständig aus dem Image heraus und beseitigt dieses Risiko an der Quelle.

Mit diesen Praktiken im Blick kommt die Wahl des richtigen Scanning-Tools auf einige konkrete Funktionen an.

Auswahl eines Container-Scanning-Tools

Die Bewertung von Container-Scanning-Tools hängt von einer Handvoll Funktionen ab, die bestimmen, wie viel realen Schutz ein Tool über die gesamte Umgebung liefert.

• Abdeckung des Lebenszyklus. Das Tool sollte über Build, Registry, CI/CD und Runtime hinweg scannen und sich nicht nur auf die statische Image-Analyse beschränken.

• agentless Deployment. Ein agentless Scanning beseitigt den Aufwand, auf jedem Workload Agenten zu installieren und zu pflegen, beschleunigt die Wertschöpfung und senkt die Betriebslast.

• Runtime-Kontext zur Priorisierung. Das Tool sollte Scan-Funde mit Runtime-Daten wie Netzwerkexponierung und Workload-Verhalten verknüpfen, damit sich nach realem Risiko statt allein nach dem CVSS-Wert priorisieren lässt.

• Tiefe der CI/CD-Integration. Native Integrationen mit vorhandenen Pipeline-Tools wie GitLab, die Fail-Fast-Richtlinien ohne eigenes Scripting unterstützen, sind hier entscheidend.

• SBOM-Erstellung. Das Tool sollte SBOMs automatisch erstellen und pflegen und so ohne manuellen Aufwand ein aktuelles Dependency-Inventar liefern.

• Abdeckung von Kubernetes und Managed Services. Das Tool sollte Kubernetes-Manifeste scannen und die Abdeckung auf gemanagte Container-Dienste über die Cloud-Anbieter hinweg ausweiten, nicht nur auf selbst verwaltete Cluster.

Wiz liefert agentless Abdeckung über den gesamten Container-Lebenszyklus, vom Dockerfile bis zur Runtime, und verknüpft jeden Fund über den Wiz Security Graph mit dem breiteren Kontext der Cloud-Umgebung. So ist eine in einem container image markierte Schwachstelle automatisch mit ihrer Runtime-Exponierung, ihrer Netzwerkerreichbarkeit und ihrer Beziehung zu anderen Ressourcen verknüpft. Das Team erhält damit eine priorisierte Ansicht statt einer flachen Liste von CVEs.

Ein Container Scanning, das auf Image-Ebene endet, lässt die aktivste Angriffsfläche unüberwacht. Um die in diesem Artikel behandelten Praktiken auf die eigene Umgebung anzuwenden, steht das Container Security Best Practices Cheat Sheet als praktische Vorlage für Build- und Runtime-Workflows zum Download bereit. Alternativ zeigt eine Demo, wie Wiz den Cloud-Security-Stack zusammenführt.

Häufig gestellte Fragen