Why 87% of Container Images Ship With a Flaw
Sysdig’s Cloud-Native Security and Usage Report found 87% of container images running in production contain at least one high or critical severity vulnerability, with the average image carrying hundreds of known CVEs. The root cause is structural: a typical container’s software supply chain averages 389 components, and when a developer writes FROM python:3.12, whatever runs in production is pulled unmodified from an image someone else published, with any flaw in that base inherited by every image built on top of it.
Key takeaways
- 87% of production container images carry a high or critical vulnerability Sysdig’s research found the average image contains hundreds of known CVEs, not an occasional outlier finding.
- Base image choice is the single highest-leverage fix Distroless images carry roughly 20 packages compared to 400+ in standard base images, directly shrinking the number of components that can carry a known vulnerability.
- Vulnerabilities propagate from parent to child images automatically A flaw in a widely-used base image is inherited by every image built on top of it, which is exactly why base image choice matters more than scanning your own application code alone.
Why the Number Is This High
Container images inherit vulnerabilities the same way software dependencies do, except the inheritance chain is often invisible to the developer actually writing application code. A standard base image bundles an entire operating system layer, package manager, shell utilities, and libraries the application itself may never use, each one a potential source of a known CVE regardless of whether the application touches that specific component. Academic research analyzing Docker Hub at scale, crawling over 12.7 million public repositories with a combined 663.8 billion historical pulls, specifically documented this parent-to-child propagation pattern: a vulnerability in a popular base image doesn't stay contained to that image, it spreads automatically to every image built FROM it, multiplying the real-world exposure far beyond the original flaw's single point of origin.
The scale this creates is genuinely large. A typical container's software supply chain averages 389 components once direct and transitive dependencies are both counted, and scanners compare that full inventory against vulnerability databases including the National Vulnerability Database, Linux distribution advisories, and vendor-specific feeds. With that many components per image, multiplied across however many images an organization actually runs in production, Sysdig's 87% figure stops looking surprising and starts looking like the predictable result of the architecture itself, not a sign that teams are being unusually careless.
Standard base images commonly bundle 400 or more packages; distroless images strip this down to roughly 20, containing only what the application actually needs to run. Fewer packages mechanically means fewer possible CVEs, independent of how carefully your own application code is written.
What Scanning Actually Catches, and When It Matters Most
Modern scanning tools, Trivy being the most widely adopted open-source option, unpack an image's layers, identify every installed package, and compare that inventory against NVD, GitHub Advisories, and vendor-specific feeds to surface known CVEs with severity ratings. The specific, practical guidance from current security practice is to scan at two distinct points rather than one: in CI/CD before an image is ever pushed to a registry, catching problems before they reach any environment at all, and again at least daily within the registry itself, since new CVEs are published continuously and an image that was clean last week may not be clean today even if nothing about the image itself changed.
This two-point approach matters because of a specific failure mode teams otherwise miss: an image scanned once at build time and never rescanned can silently accumulate real risk simply by sitting in a registry while new vulnerabilities are discovered in its existing, unchanged components. Daily rescanning closes that gap without requiring any new build or deployment, since the risk is coming from newly disclosed vulnerabilities in old, already-built software, not from anything changing in the image itself.
A Practical Reduction Checklist
What actually reduces real container vulnerability exposure
This is the single highest-leverage structural fix, reducing package count by roughly 20x in the distroless case.
This catches known vulnerabilities before an image ever reaches a shared or production environment.
New CVEs are published continuously, meaning an image clean yesterday may not be clean today.
A software bill of materials gives a complete, trackable inventory of what’s actually inside each image.
Hundreds of low-severity findings matter less than a single actively exploited critical one.
Who Should Weight This Most Heavily
- Minimal base images deliver a large, structural reduction in attack surface with no application code changes
- Open-source scanners (Trivy, Grype) are free and integrate directly into existing CI/CD pipelines
- Two-point scanning (build-time and daily registry) closes the gap left by scanning only once
- 87% of production images currently carry at least one high or critical vulnerability, per Sysdig’s research
- Vulnerabilities propagate automatically from base images to every image built on top of them
- A typical image’s 389-component supply chain is genuinely hard to fully track without SBOM tooling
Exploring the wider developer toolkit
See our full cloud and developer tools guide for container, Kubernetes and infrastructure comparisons.
Our Sources
Where this comes from
The core vulnerability prevalence figure is drawn directly from Sysdig’s Cloud-Native Security and Usage Report, a named, established industry research source. Supply chain scale figures and the parent-child propagation pattern are drawn from academic research analyzing Docker Hub at scale, cross-checked against current container scanning practice documentation for consistency.
-
Sysdig research cited directly
The 87% high/critical vulnerability prevalence figure drawn from this specific, named, established industry report.
-
Academic Docker Hub analysis cited
The parent-to-child vulnerability propagation pattern and registry scale figures drawn from published academic research analyzing the Docker Hub ecosystem directly.
-
Scanning best practice cross-checked
Two-point scanning guidance (CI/CD plus daily registry rescanning) verified against multiple independent 2026 container security sources.
Frequently Asked Questions
Frequently asked questions
What percentage of container images actually have security vulnerabilities?
Sysdig’s Cloud-Native Security and Usage Report found 87% of container images in production contain at least one high or critical severity vulnerability, with the average image carrying hundreds of known CVEs.
Why do minimal or distroless base images help so much?
Standard base images commonly bundle 400 or more packages, while distroless images contain roughly 20, a direct, structural reduction in the number of components that could carry a known vulnerability, independent of how the application code itself is written.
How often should container images actually be rescanned?
Current practice recommends scanning in CI/CD before pushing to a registry, then rescanning registry images at least daily, since new CVEs are published continuously against existing, unchanged software.
Do vulnerabilities in a base image affect every image built from it?
Yes. Academic research analyzing Docker Hub at scale specifically documented this parent-to-child propagation: a flaw in a widely-used base image is inherited automatically by every image built on top of it.
How many software components does a typical container actually have?
A typical container’s software supply chain averages 389 components once both direct and transitive dependencies are counted, which is why manual tracking is impractical and automated scanning tools are standard practice.
Final take
- 87% of production container images carry a high or critical vulnerability, per Sysdig's research
- A typical image's software supply chain averages 389 components, mostly inherited from the base image
- Distroless base images cut package count from 400+ to roughly 20, a direct structural fix
The 87% figure isn’t evidence of unusually careless engineering, it’s the predictable result of an architecture where a typical image inherits 389 components from a base image chain most developers never fully audit, and where any flaw in a popular base image propagates automatically to every image built on top of it. Minimal base images address this at the structural level, cutting package count by roughly 20x in the distroless case, while two-point scanning, at build time and daily in the registry, catches both what you build and what gets newly discovered in what you already shipped.
