Was ist Container Image Scanning?
Container Image Scanning ist der automatisierte Prozess, bei dem Container Images auf Schwachstellen, Fehlkonfigurationen und Compliance-Verstöße analysiert werden. Dieser Prozess untersucht alle Ebenen eines Container Images, darunter das Basis-Betriebssystem, die Anwendungsabhängigkeiten, die Bibliotheken und die Konfigurationsdateien.
Container Image Scanning ist in erster Linie eine statische Analyse, die Images vor dem Deployment prüft. Ergänzend dazu setzen Unternehmen auf Runtime-Überwachung, um zu bewerten, welche Schwachstellen in produktiven Umgebungen tatsächlich ausnutzbar sind. Das statische Scanning erkennt Probleme früh im Entwicklungsprozess, während die Runtime-Überwachung Kontext zu aktiven Bedrohungen und geladenen Paketen liefert.
Container Images sind unveränderliche Momentaufnahmen, die alles enthalten, was zum Ausführen einer Anwendung nötig ist. Da diese Images statisch sind, übertragen sich Schwachstellen im Basis-Image auf alle Container, die daraus entstehen. Deshalb ist es entscheidend, jede einzelne der Image-Ebenen zu prüfen, um versteckte Sicherheitsrisiken aufzuspüren.
Warum Container Image Scanning für die Cloud-Sicherheit entscheidend ist
Container sind von Natur aus kurzlebig. Laut dem Cloud-Native Security and Usage Report 2023 von Sysdig existieren viele containerisierte Workloads in produktiven Umgebungen weniger als fünf Minuten. Klassische Sicherheitsansätze, die auf dauerhafter Infrastruktur beruhen, greifen hier nicht. Diese schnelle Fluktuation führt zu Container-Wildwuchs und erzeugt blinde Flecken, sobald Unternehmen Tausende Container über mehrere Umgebungen hinweg ohne ausreichende Transparenz betreiben.
Im Shared-Responsibility-Modell müssen Unternehmen die Container Images absichern, die sie selbst erstellen oder einsetzen. Das ist für die Supply Chain Security zentral, denn Basis-Images von Drittanbietern und Open-Source-Komponenten bergen oft verborgene Risiken. Ein einziges verwundbares Image kann mehrere Workloads kompromittieren, sobald es über verschiedene Deployments hinweg wiederverwendet wird. Besonders kritisch ist das, weil 87 % der Container Images Schwachstellen mit hohem oder kritischem Schweregrad enthalten.
Ein Shift-Left-Security-Ansatz (frühzeitige Verlagerung der Sicherheit in den Entwicklungsprozess) hilft, Schwachstellen vor der Produktion zu erkennen. Das reduziert Risiken und senkt die Kosten für die Behebung deutlich. Werden Container mit erhöhten Rechten betrieben – etwa mit Root-Zugriff oder überflüssigen Berechtigungen –, werden sie zu attraktiven Angriffszielen. Das Prinzip der geringsten Berechtigung reduziert diese Angriffsfläche erheblich: Container laufen dann als Nicht-Root-Benutzer und verzichten auf unnötige Linux-Berechtigungen. Compliance-Frameworks fordern ein Schwachstellenmanagement in unterschiedlicher Detailtiefe. PCI DSS schreibt vierteljährliches Vulnerability Scanning ausdrücklich vor (Anforderung 11.2). HIPAA verlangt risikobasierte Schwachstellenbewertungen gemäß der Security Rule. SOC 2 bewertet, ob Unternehmen wirksame Kontrollen für Änderungsmanagement und Risikoüberwachung besitzen. Container Image Scanning hilft, diese Kontrollen bei Audits nachzuweisen.
So funktioniert Container Image Scanning
Der Scanning-Prozess beginnt mit der Zerlegung des Images: Scanner extrahieren und analysieren jede einzelne der Image-Ebenen. Anschließend erkennen Methoden zur Paketerkennung die installierte Software, die Bibliotheken und die Abhängigkeiten innerhalb dieser Ebenen.
Scanner gleichen die Ergebnisse mit Schwachstellendatenbanken ab und vergeben Schweregrade über Systeme wie das CVSS-Scoring. Viele Tools erzeugen zudem eine SBOM (Software Bill of Materials), um jede Komponente im Image nachzuvollziehen.
Über reine Software-Fehler hinaus führen Scanner eine Secrets-Erkennung durch und finden API-Schlüssel, Passwörter und Zertifikate, die in Images eingebettet sind. Die Konfigurationsanalyse prüft auf unsichere Einstellungen, etwa Container, die als Root laufen, oder unnötig offene Ports.
Das geschieht entweder beim Registry Scanning für ruhende Images oder beim Pipeline Scanning während des Build-Prozesses. Moderne Scanner liefern Hinweise zur Behebung und empfehlen häufig sicherere Basis-Images, um Probleme schnell zu beheben.
Arten von Container-Schwachstellen, die das Scanning erkennt
Schwachstellen im Betriebssystem: hierbei handelt es sich um Risiken in Basis-OS-Paketen, die alle Container betreffen, die aus diesem Image entstehen;
Schwachstellen in Anwendungsabhängigkeiten: diese Fehler stecken in sprachspezifischen Paketen (etwa npm, pip oder Maven) und in Bibliotheken, die eine Anwendung nutzt;
Konfigurationsprobleme: Fehlkonfigurationen umfassen unsichere Standardeinstellungen, schwache Berechtigungen oder offene Ports, die Container angreifbar machen;
eingebettete Secrets: hier gelangen Zugangsdaten, API-Schlüssel und Zertifikate versehentlich in Images;
Malware und Backdoors: Scanner erkennen schädlichen Code, der über Angriffe auf die Lieferkette in Images eingeschleust wird;
Compliance-Verstöße: das sind Abweichungen von Sicherheits-Benchmarks wie dem CIS Docker Benchmark;
Lizenzprobleme: Scanner erkennen Konflikte bei Open-Source-Lizenzen, die rechtliche Risiken für ein Unternehmen schaffen können.
Signieren von Images und Prüfung der Herkunft
Das Signieren von Images liefert einen kryptografischen Nachweis, dass Images zwischen Build und Deployment nicht manipuliert wurden. Unternehmen nutzen Signaturen, um Vertrauen in ihre Container-Lieferkette aufzubauen.
So funktioniert das Signieren: Build-Systeme erzeugen für jedes Image eine kryptografische Signatur mit einem privaten Schlüssel. Die Signatur und die Metadaten – wer das Image wann und aus welcher Quelle erstellt hat – werden als Attestierung gespeichert. Beim Deployment prüfen Admission Controller die Signatur mit dem passenden öffentlichen Schlüssel, bevor das Image laufen darf.
Gängige Ansätze zum Signieren:
Sigstore Cosign: ein Open-Source-Tool, das Container Images signiert und verifiziert und dabei auch schlüssellose Signaturen ermöglicht;
Docker Content Trust: integriertes Signieren für Docker Images über Notary;
Cloud-natives Signieren: AWS Signer, das Signieren in der Azure Container Registry sowie Google Binary Authorization.
Herkunftsnachweise gehen über das reine Signieren hinaus und dokumentieren den gesamten Build-Prozess: das Quell-Repository, den Commit-Hash, die Build-Parameter und die Abhängigkeiten. Das unterstützt die Compliance mit dem SLSA-Framework (Supply chain Levels for Software Artifacts) und hilft Sicherheitsteams, Images bis zum Quellcode zurückzuverfolgen.
Kategorien von Container-Scanning-Tools
Unternehmen wählen je nach Architektur und Anforderungen aus mehreren Scanning-Ansätzen:
Registry-native Scanner lassen sich direkt in Container Registries integrieren (Amazon ECR, Azure ACR, Google GCR, Docker Hub). Diese Scanner analysieren Images automatisch, sobald sie in die Registry gepusht werden, und stellen die Ergebnisse in der Registry-Oberfläche bereit. Sie eignen sich für Teams, die ohne zusätzliche Infrastruktur scannen möchten.
In CI/CD integrierte Scanner laufen als Pipeline-Schritte während der Image-Builds. Sie brechen Builds ab, die gegen Sicherheitsrichtlinien verstoßen, und geben Entwicklungsteams sofort Rückmeldung. Sie eignen sich für Shift-Left-Security und verhindern, dass Schwachstellen in Registries gelangen.
Open-Source-Scanning-Tools bieten Flexibilität und lassen sich ohne Lizenzkosten anpassen. Unternehmen integrieren sie in bestehende Abläufe und erweitern ihre Funktionen. Sie eignen sich für Teams, die Ressourcen im Engineering haben, um die Scanning-Infrastruktur zu pflegen.
Einheitliche CNAPP-Plattformen verbinden Container Scanning mit cloud security posture management, Runtime-Schutz und der Analyse über einen Security Graph. Diese Plattformen verknüpfen Container-Schwachstellen mit Cloud-Kontext – Angriffsfläche im Netzwerk, Berechtigungen, Zugriff auf sensible Daten – und priorisieren so die realen Risiken. Sie eignen sich für Unternehmen, die eine umfassende cloud-native Sicherheit mit weniger Tool-Wildwuchs suchen.
Deployment-Strategien für Container Image Scanning
Beim Registry Scanning werden Images analysiert, die in Container Registries wie Docker Hub, ECR, GCR oder ACR liegen, bevor sie abgerufen werden. Die CI/CD-Integration ermöglicht ein Inline-Scanning während des Build-Prozesses und blockiert riskante Builds über Gates zur Durchsetzung von Richtlinien.
Die Pre-Deployment-Validierung scannt Images in Staging-Umgebungen, bevor sie in die Produktion überführt werden. Ein kontinuierliches Scanning überwacht bereits ausgerollte Images fortlaufend und alarmiert Sicherheitsteams, sobald neue Schwachstellen (CVEs) bekannt werden, die bereits laufende Pakete in der Produktion betreffen. So können Unternehmen auch nach dem Deployment schnell reagieren.
Zur Wahl stehen agentless Scanning und agent-based Ansätze. Agentless Scanning nutzt APIs und liefert vollständige Abdeckung ohne Performance-Einbußen und ohne den Wartungsaufwand installierter Agenten.
Für eine Defense-in-Depth-Strategie sollte das Scanning an mehreren Stellen ansetzen: beim Build, in der Registry und zur Runtime. Diese Scans lassen sich in bestehende DevOps-Tools wie Jenkins, GitLab und GitHub Actions integrieren.
Herausforderungen bei der Umsetzung
Container Image Scanning ist für die Cloud-Sicherheit unverzichtbar. Dennoch stoßen Unternehmen auf mehrere praktische Herausforderungen, wenn sie Scanning-Programme im großen Maßstab umsetzen.
Alert Fatigue: das Scanning erzeugt oft Tausende Funde, die sich ohne Kontext kaum priorisieren lassen;
False Positives: Scanner melden mitunter Schwachstellen, die in einer konkreten Umgebung gar nicht ausnutzbar sind;
Performance-Einfluss: aufwendige Scanning-Prozesse können CI/CD-Pipelines oder produktive Workloads verlangsamen;
Lücken in der Abdeckung: blinde Flecken entstehen, wenn nur einige Registries gescannt werden oder Runtime-Kontext fehlt;
Komplexe Behebung: es lässt sich oft schwer bestimmen, welche Schwachstellen sofort behoben werden müssen und welche warten können;
Reibung für Entwicklungsteams: Entwicklungsteams lehnen das Scanning ab, wenn es Deployments blockiert oder zu viel manuelle Arbeit erzeugt.
Ein kontextbezogenes Scanning löst diese Probleme, indem es Schwachstellen mit Angriffsfläche, Berechtigungen und sensiblen Daten verknüpft.
Wirksamkeit des Container Scannings messen
Die folgenden Kennzahlen belegen Sicherheitsfortschritte und die Reife eines Programms:
Kennzahlen zu Schwachstellen:
Anteil der Images ohne kritische oder hohe Schwachstellen: für produktive Images gilt ein Ziel von 95 % oder mehr;
durchschnittliche Behebungszeit (MTTR) nach Schweregrad: kritisch unter 24 Stunden, hoch unter 7 Tagen, mittel unter 30 Tagen;
Schwachstellendichte: durchschnittliche Anzahl an CVEs pro Image, mit sinkender Tendenz über die Zeit;
Behebungsquote: Anteil der erkannten Schwachstellen, die innerhalb des SLA behoben werden.
Kennzahlen zum Prozess:
Scan-Abdeckung: Anteil der Images, die vor dem Deployment gescannt werden (Ziel: 100 %);
Quote der Richtlinien-Compliance: Anteil der Builds, die die Sicherheits-Gates im ersten Anlauf bestehen;
Verbreitung des Image-Signierens: Anteil der produktiven Images mit gültigen Signaturen;
Rate der SBOM-Erzeugung: Anteil der Images mit aktueller SBOM.
Kennzahlen zum Betrieb:
Abweichung von Basis-Images: wie schnell Teams auf gepatchte Basis-Images umstellen;
Anzahl der Ausnahmen: Zahl der aktiven Ausnahmen für Schwachstellen, mit sinkender Tendenz;
False-Positive-Rate: Anteil der gemeldeten Schwachstellen, die im jeweiligen Kontext nicht ausnutzbar sind;
Zufriedenheit der Entwicklungsteams: Umfragewerte zur Bedienbarkeit des Scanning-Tools und zur empfundenen Reibung.
Diese Kennzahlen helfen Sicherheitsverantwortlichen, den Nutzen nachzuweisen, Lücken im Prozess zu erkennen und den Sicherheitsstatus ihrer Container fortlaufend zu verbessern.
Der Ansatz von Wiz für Container Image Scanning
Wiz bietet agentless Scanning über die gesamte Cloud-Umgebung hinweg – ohne Performance-Einfluss und ohne komplexes Deployment. Der Wiz Security Graph verknüpft Container-Schwachstellen mit der Angriffsfläche zur Runtime, mit Netzwerkpfaden und dem Zugriff auf sensible Daten und deckt so reale Angriffspfade auf.
Wiz Code erweitert das Scanning in die CI/CD-Integration und setzt Richtlinien durch, die verwundbare Container von der Produktion fernhalten. WizOS stellt gehärtete Container Images mit nahezu null CVEs bereit, die aus dem Quellcode erstellt und von Wiz gepflegt werden. So startet ein Team mit einer sichereren Basis und muss weniger Aufwand in das Verwalten von Image-Schwachstellen und in das Patchen stecken.
Der Runtime-Kontext des Wiz-Sensors bestätigt, welche Schwachstellen in einer konkreten Umgebung tatsächlich ausnutzbar sind. Die einheitliche Transparenz über Code, Container und Cloud beseitigt Tool-Wildwuchs und deckt die gesamte Angriffsfläche ab.
Tausende Alarme zu Container-Schwachstellen lassen sich in eine priorisierte Liste realer Angriffspfade verwandeln. Eine Demo zeigt, wie das graphbasierte, agentless Scanning von Wiz einheitliche Transparenz über Code, Container und Cloud liefert – ohne Agenten, ohne Performance-Einfluss und ohne komplexes Deployment.
Kann Container Scanning Zero-Day-Schwachstellen erkennen?
Das Scanning erkennt bekannte Schwachstellen aus Datenbanken, aber keine unbekannten Zero-Days. Verhaltensanalyse und Runtime-Überwachung sind nötig, um das Scanning bei unbekannten Bedrohungen zu ergänzen.
Wie stark beeinflusst das Scanning von Containern in der Produktion die Performance?
Agentless Scanning hat keinen Einfluss auf die Performance, während agent-based Ansätze die Leistung der Workloads beeinträchtigen können. Idealerweise findet das Scanning vor dem Deployment statt, ergänzt durch eine leichtgewichtige Runtime-Überwachung im laufenden Betrieb.
Wie funktioniert Container Scanning in isolierten Umgebungen ohne Internetzugang?
Das Scanning in isolierten Umgebungen erfordert lokale Schwachstellendatenbanken und Offline-Scanning-Tools. Unternehmen können private Registries mit bereits gescannten, freigegebenen Images vorhalten und so ohne Internetzugang für Sicherheit sorgen.