Software teams have become very good at creating container images. They are far worse at retiring them.
Containerization packages an application with the code, dependencies, and system components it needs to run. That consistency makes software easier to build, move, and deploy.
It also makes creating a new image almost effortless. Every pull request, CI build, feature branch, and release can produce another one. Over time, those images accumulate across registries.
This is container sprawl: the uncontrolled accumulation of container images, tags, and running instances beyond a team’s ability to track, govern, and secure them.
The security impact is significant. CISA's January 2025 container-hardening guidance found that 67% of container breaches traced back to misconfigured RBAC, exposed APIs, or stale images. Stale images are one of the most persistent outcomes of container sprawl.
Where Container Sprawl Shows Up
Container sprawl appears in two related layers:
- Image sprawl is the buildup of stored images and tags in registries.
- Runtime sprawl is the growth of deployed containers and clusters.
This article focuses on image sprawl, because it is where much of the security debt begins.
Each image was a small decision that made sense at the time. Together, they create an attack surface nobody planned, and few organizations can measure.
Every image is an artifact that must be inventoried, maintained, patched, and eventually retired. Yet CI/CD pipelines can create images far faster than teams can manage them. By the time a registry holds hundreds or thousands of images, simply knowing what exists becomes difficult, before anyone even begins assessing the vulnerabilities inside.
How Container Sprawl Happens
Container sprawl takes hold when image creation is distributed but image governance is not. Teams build and publish images across repositories, CI pipelines, registries, and cloud environments, often with different conventions and no shared inventory.
The estate then fragments. VMware reported that 61% of enterprises ran 10 or more clusters in 2025, and Red Hat found OpenShift customers averaging 2.7 cloud providers per deployment. Every cluster and cloud environment creates another location for images and another governance boundary to cross.
A copy-fork-modify culture adds to the problem. A team pulls a base image, makes a small change, pushes a new version, and loses the original lineage. Over time, teams use different base operating systems, package versions, and runtimes, with no central view tying those choices together.
Finally, most images have no defined end of life. Registries often lack effective lifecycle policies, so tags remain available until someone deliberately removes them. An image created for a short-lived test or a 2023 release can remain pullable long after its original purpose has disappeared.
The Illusion of the Single Artifact
Here is the insight that turns sprawl from a tidiness problem into a security problem.
A container image looks like a single, self-contained artifact. Pull it, run it, done. In reality, an image is built from layers that include application dependencies, operating system packages, and foundational libraries such as glibc and OpenSSL. Teams may not have chosen many of those components directly, and they may not know exactly which images inherit them.
The application code might be only a few hundred lines. Underneath it can sit a base image carrying hundreds of packages. Addressing a vulnerability may require rebuilding the image with an updated base or dependency set, then identifying every image and deployment that still relies on the older version.
Now multiply that hidden dependency load across thousands of forgotten images. A flaw in a widely used base layer can affect every image built from it. The issue is not simply how many images sit in a registry. It is how many images inherit software that nobody has identified, assigned, or maintained.
Container sprawl multiplies inherited risk across too many artifacts. That makes vulnerability management slower, creates duplicate findings, and makes it harder to determine which images are actually affected when a new CVE is disclosed.
Stale-Image and Reintroduction Risk
A stale image is not necessarily an active attack surface simply because it exists in a registry. The risk increases when it remains accessible, pullable, or capable of being deployed again.
Stale images fall behind as new vulnerabilities are disclosed. An image built a year ago retains the package versions it contained when it was created. If vulnerabilities are later disclosed in those versions, the image will remain affected until the team rebuilds it with updated components. Regular image scanning and timely remediation are therefore essential. CISA container image hygiene guidance
Deleting a deployment does not delete the image. An old image can remain in a registry after the workload that used it is gone. If a deployment later references an old tag or manifest, that image can be pulled and run again. This is especially difficult to control across multiple registries and cloud environments. Using immutable digests helps ensure that a workload runs the exact image that was reviewed. Kubernetes image documentation
Incomplete SBOMs make stale images harder to assess. An SBOM should provide an accurate inventory of the components inside an image. If it is missing, incomplete, or does not match the image that was deployed, teams can miss vulnerable packages and struggle to determine which images require remediation.
Dimension | Active, Governed Image | Stale or unmanaged Image |
|---|---|---|
Maintenance | Rebuilt or reviewed on a defined cadence | May not have been rebuilt, reviewed, or retired recently |
Vulnerability Status | Scanned and remediated through an established process | May contain components affected by newly disclosed vulnerabilities |
Ownership | Traceable to a team and a defined purpose | Ownership or intended use is unclear |
Inventory visibility | Recorded in the inventory and linked to deployments where possible | May be missing from the inventory or disconnected from deployment records |
Deployment control | Uses approved sources, policies, and preferably an immutable digest | May remain accessible and could be accidentally pulled or redeployed |
Response readiness | Team can identify its use and prioritize remediation | Team may need to investigate whether it is used, affected, or safe to remove |
Common Forms of Container Sprawl
Unpipelined images are built or pushed outside the approved delivery process. A developer may build an image locally and push it to a shared registry for a quick test, or a team may use a registry that the central platform does not monitor. These images can bypass the scanning, signing, and policy checks built into the standard pipeline.
Orphaned images are artifacts that no known deployment uses and no team actively owns. The application that once used them may be gone, but the image remains in the registry. Without a retention policy or ownership record, teams may not know whether it is safe to remove or whether it could still be pulled again.
Duplicate and fragmented images are multiple tags, rebuilds, or registry copies that represent the same application or closely related versions. They create redundant scan findings, obscure lineage, and make it harder to identify the supported version of an application.
The common thread is governance. Without a unified view across registries and clusters, teams cannot reliably identify what they have, what is running in production, who owns it, or which artifacts are safe to retire.
The Cost of Container Sprawl
The bill comes in two forms.
The security cost is slower vulnerability response and a greater chance that outdated images remain available for deployment. When a critical CVE affects a common library, the first questions are: where is it running, which images contain it, and who owns those images? In a sprawling estate, answering those questions can take hours or days. That delay extends the time a vulnerable deployed workload may remain exposed.
The operational and financial cost is quieter but real:
- Storage costs grow as unused images and layers remain in registries.
- Replication, pulls, and transfers can increase network costs across registries and cloud environments.
- Scanners flag the same inherited CVEs across many similar images, creating duplicate findings and alert fatigue.
- Engineers spend time investigating images that may no longer be deployed or needed.
There is also a capacity mismatch underneath the cost. Images accumulate automatically at pipeline speed, around the clock. Cleanup, ownership decisions, and vulnerability triage happen at human speed, within sprint capacity that is already limited. Unless teams automate governance and retirement, that gap widens over time.
Ways to Keep Container Sprawl Under Control
Container sprawl is tractable when teams combine visibility, lifecycle controls, and standardized build practices.
- Build a continuous inventory across registries and clusters. Maintain an up-to-date view of what exists, what is deployed, where it runs, and which team owns it. Point-in-time scans quickly become outdated.
- Assign ownership and purpose to every image. Each image should be traceable to a team, application, environment, and lifecycle status. An artifact without a known owner becomes future debt.
- Enforce lifecycle and retention policies. Automatically clean up untagged images and artifacts that meet defined age, usage, and approval criteria. Use exceptions for images required for rollback, audit, or long-term support.
- Standardize approved base images. Give teams a small, maintained set of base-image families rather than allowing unmanaged forks. This reduces variation and makes patching more consistent.
- Consolidate duplicate and legacy images. Identify redundant tags, similar rebuilds, and obsolete variants. Consolidation reduces the number of artifacts teams must track, scan, and maintain. In a 120-image estate, for example, SBOM fingerprinting may identify only five base families and reveal substantial duplicate vulnerability findings.
- Deploy by digest and require trusted signatures. Use immutable digests to ensure workloads run the reviewed image version. Require signatures or admission policies to prevent unapproved images from entering production.
- Build smaller, purpose-specific images. Fewer packages and unnecessary tools reduce the number of components that must be tracked and maintained.
Governing container sprawl
The question is not, “How many images do we have?” It is, “How many of those images do we understand?”
Can you identify which images are running in production, which are duplicates, which are no longer used, and which contain outdated components? Can you trace each one to an owner, a purpose, and an approved base image?
Organizations that can answer those questions are actively managing their software supply chain. Those that cannot are carrying hidden security and operational debt.
Container sprawl is not solved by deleting old tags alone. It requires continuous inventory, clear ownership, lifecycle controls, and a deliberate effort to reduce the number of images that must be governed.
Want to see what container sprawl looks like in your environment? Schedule a live CleanSight demo to identify duplicate and unused artifacts, map image vulnerabilities, and uncover consolidation opportunities across your container estate.
