Security teams scanning production Kubernetes clusters this quarter are running into the same uncomfortable finding, cluster after cluster: a large share of the container images actually serving traffic were built weeks, months, or in some cases years before they were last redeployed. Independent scans conducted across cloud-native environments in the first half of 2026 continue to show that somewhere between 60% and 80% of running containers are based on an image with at least one known-fixed critical or high-severity vulnerability sitting in a base layer nobody has rebuilt. The base images are usually not exotic — they're the same node, python, alpine, and debian-derived images that make up the backbone of most software supply chains. The problem isn't obscure software. It's stale software that everyone assumed was current.
This is not a new phenomenon, but it has become a persistent one, and it is increasingly the subject of formal industry reporting rather than anecdote. Multiple cloud security vendors' 2025-2026 state-of-cloud-security reports converged on a similar figure: the median age of a "current" production container image, measured from its last rebuild date, sits well past 90 days, and a meaningful long tail stretches past a full year. For an ecosystem that markets itself on immutability and rapid redeployability, container infrastructure has developed a quiet aging problem.
The Gap Between "Deployed" and "Current"
Containers were supposed to fix the patching problem that plagued long-lived virtual machines. Instead of patching a live host in place, teams rebuild an image from a Dockerfile and redeploy the whole thing — in theory, a clean, repeatable, low-risk operation. In practice, the rebuild step is the part that gets skipped.
The pattern shows up consistently in scan data: application code changes trigger frequent rebuilds, but base image bumps do not. A service can go through forty deploys in a quarter without a single one of them updating the parent image tag in the Dockerfile's FROM line. Each of those forty deploys ships the same outdated OS packages, the same outdated language runtime, and the same outdated set of transitive dependencies baked into the base layer — accumulating CVEs the whole time, invisibly, because nothing in the CI pipeline flags a base image as stale unless something is explicitly checking for it.
Compounding this, a large fraction of organizations still pin base images to floating tags like latest, lts, or a major-version tag such as python:3.11, under the assumption that this keeps them current. It does the opposite in effect: because the actual image digest is only resolved once and cached in most build systems, teams can run the same digest for months while believing the tag guarantees freshness. Registry telemetry reviewed across recent industry reports shows a significant share of latest-tagged production images have not actually pulled a new digest in over six months.
Why This Keeps Happening
Three structural reasons keep surfacing across incident reviews and audits:
Rebuilds are decoupled from patch releases. Base image maintainers ship security patches on their own schedule — sometimes within hours of a CVE disclosure — but that patch only reaches a running workload if someone triggers a rebuild and redeploy of every dependent image. Most CI systems have no automated hook that says "a critical CVE just landed in your base image, rebuild now." The dependency is manual, and manual steps get deferred.
Ownership is unclear. In most organizations, the team that owns a Dockerfile is an application team, not the platform or security team that tracks CVE disclosures. Security has visibility into the vulnerability; application teams have the ability to fix it. Without a workflow that connects the two, the vulnerability sits in a queue that nobody is actively watching, and it competes for engineering time against feature work that has a more visible owner and deadline.
Scanners flag volume, not risk. Traditional image scanning tools report every CVE present in every layer, often producing hundreds or thousands of findings per image. Faced with that volume and no prioritization signal, teams reasonably triage by severity score alone — which still leaves an overwhelming backlog, much of which is not actually exploitable in the deployed workload. The result is scanner fatigue: teams stop trusting the report enough to act on it consistently, and stale images stay in rotation because "everything is red anyway."
What Recent Findings Show
Recent security industry reporting on this trend converges on a few consistent data points worth noting for anyone benchmarking their own environment:
- A large majority of scanned production clusters contain at least one image where the base OS has reached, or is within months of reaching, end-of-life support status — meaning no further security patches will be issued for it at all, regardless of whether anyone rebuilds.
- The most common vulnerable components found in stale base layers are not application-level dependencies but low-level OS packages — libc variants, OpenSSL, compression libraries, and shell utilities — that are present by default and rarely touched by application developers.
- Time-to-remediation for base image CVEs, once flagged, remains far longer than for application-dependency CVEs, largely because base image updates carry a higher (if often overstated) perceived risk of breaking compatibility, so teams schedule them cautiously rather than urgently.
- A nontrivial share of the images running in production trace back to internal "golden images" that were hardened and approved at one point but have not been re-certified since, meaning the "approved" label itself has become stale.
None of these findings describe a single catastrophic breach. They describe a slow accumulation of exposure that raises the odds of one — the kind of latent risk that turns a routine CVE disclosure into an actual incident, because the vulnerable version is still running somewhere nobody remembered to check.
The Cost of Letting Images Age
The risk isn't hypothetical. Attackers increasingly automate scans for known-vulnerable service banners and package versions across the public internet within hours of a CVE's public disclosure, specifically because they know a meaningful percentage of internet-facing workloads will still be running the vulnerable version weeks or months later. An outdated image sitting in production is, from an attacker's perspective, simply a wider window of opportunity — and the data shows that window frequently stays open far longer than defenders assume.
There's also a compliance dimension that's becoming harder to ignore. Frameworks increasingly expected by enterprise customers and auditors — including provisions tied to SOC 2, and supply-chain attestation requirements referencing SBOM and provenance data — assume organizations can demonstrate what's actually running in production, not just what was approved in a build pipeline weeks or months ago. An outdated image that was scanned once at build time but never rescanned against newly disclosed CVEs represents a compliance gap as much as a security one: the attestation on file no longer reflects the artifact's real risk posture.
Closing the Gap Requires Continuous Visibility, Not Point-in-Time Scans
The consistent theme across this data is that a one-time scan at build time is not sufficient. CVEs get disclosed continuously, base images age continuously, and production environments drift continuously — so the only defensible posture is continuous monitoring of what's actually deployed, cross-referenced against what's newly known to be vulnerable, with a fast and low-friction path to remediation. Organizations that have made real progress on this problem share a common pattern: they've moved image freshness from a manual quarterly audit into an automated, always-on control tied directly to their deployment pipeline.
How Safeguard Helps
Safeguard is built to close exactly this gap between what's deployed and what's actually current. Safeguard continuously ingests or generates SBOMs for every running container, then applies reachability analysis to determine which flagged vulnerabilities in aging base layers are actually exploitable in the deployed workload versus present-but-inert — cutting through the alert volume that causes teams to disengage in the first place. Griffin AI, Safeguard's reasoning engine, prioritizes stale and vulnerable images by real-world exploitability and blast radius rather than raw CVSS score, so teams know which base image rebuilds matter this week and which can wait. When a fix is available, Safeguard doesn't stop at the alert: it opens an auto-fix pull request that bumps the base image tag, resolves the dependency, and hands the team a reviewable diff instead of a backlog item. The result is a production environment where image staleness is caught and corrected continuously, not discovered months later during an incident or an audit.