Registry scans miss live Kubernetes drift as fixes lag deployment

At a glance

What this is: This is an analysis of why registry scanning alone misses live Kubernetes exposure when running workloads drift from the image state in the registry.

Why it matters: It matters because identity and access controls around clusters, service accounts and deployment paths only work if teams can reconcile what was built with what is still running.

By the numbers:

• Critical vulnerabilities went from a 7-day average in 2024 to 12 days in 2025, according to Red Hat Product Security Risk Report 2025 cited by Anchore.
• Low-severity fixes went from 115 days in 2024 to 204 days in 2025, according to Red Hat Product Security Risk Report 2025 cited by Anchore.
• CVE-2025-32463 was added to CISA's Known Exploited Vulnerabilities catalog 3 months after disclosure, according to Anchore.

Context

Container security often focuses on what enters the registry, but that is only one point in the workload lifecycle. Once a deployment reaches Kubernetes, the live state can diverge from the approved image faster than many control planes assume, which creates a gap between artifact governance and runtime exposure.

That gap has an identity and access dimension because runtime visibility depends on who and what can query the cluster, which service account is used, and whether the inventory path is narrowly scoped or overprivileged. In practice, container drift is not just a DevSecOps problem but a governance problem about authoritative state.

The article treats this as a common operational failure mode rather than an edge case, which is consistent with how fast-moving clusters behave under manual deployments, delayed patching and pipeline bypasses.

Key questions

Q: What breaks when registry scanning is the only container security control?

A: Registry-only scanning misses the running state of Kubernetes workloads, so patched images can sit idle in the registry while vulnerable pods continue to execute in production. That breaks exposure validation, incident response and audit evidence because the control measures what was built, not what is still live.

Q: Why does container drift create such a large operational risk?

A: Drift extends the time between a fix becoming available and the vulnerable workload disappearing from production. In fast-moving clusters, that window can last long enough for exploitation, failed compliance deadlines or inaccurate reporting to the business.

Q: How do security teams know if Kubernetes inventory is actually working?

A: It is working when the inventory can answer, with confidence, which images are scheduled in each namespace, whether those images are identified by digest, and whether runtime policy flags the same vulnerable artifact across clusters. If the answer still depends on manual cross-checks, the control is incomplete.

Q: When should organisations prioritise runtime inventory over more registry scans?

A: Prioritise runtime inventory when patching is delayed, deployments are manual, or auditors and regulators need evidence of what was live at a specific point in time. In those conditions, more registry scans add noise, while live reconciliation changes the outcome.

Technical breakdown

Why registry scans miss live cluster exposure

A registry scan inspects stored images, tags and metadata at rest. Kubernetes exposure is determined by what is scheduled, rescheduled and actually executing at runtime. If a deployment is rolled out manually, if a node caches an older layer, or if a pod is never restarted after a patch, the registry can show a fixed image while the cluster still runs the vulnerable one. That difference matters because the authoritative source of truth for risk is the live workload, not the artifact repository. Runtime inventory closes that gap by querying the cluster directly and reconciling scheduled images against policy.

Practical implication: Use live cluster inventory, not registry state alone, to decide whether a workload is still exposed.

Why image digests matter more than mutable tags

Mutable tags such as latest are convenient for delivery but weak for governance because the same tag can point to different image contents over time. Digest-based tracking binds the workload to an immutable artifact identity, which is what you need when reconstructing what was running on a specific date or proving that a patched image was actually deployed. Without digest-level control, drift analysis becomes ambiguous and compliance evidence becomes easy to challenge. This is especially relevant in Kubernetes, where the same deployment pattern may be re-pulled many times across namespaces and clusters.

Practical implication: Track runtime images by digest so audit evidence and exposure analysis stay stable over time.

How runtime policy enforcement changes the control model

Build-time controls tell you whether an image passed checks before release. Runtime policy adds a second enforcement point that evaluates what is already running and can flag or block workloads that fall outside policy. That matters when the real problem is delay between fix availability and full rollout, which is where exposure often persists. A continuous inventory plus admission control creates a closed loop: observe the live state, compare it to policy, and stop non-compliant workloads from persisting unnoticed. The control shift is from point-in-time attestation to continuous reconciliation.

Practical implication: Pair inventory with admission policy so vulnerable workloads are governed after deployment, not only before it.

Threat narrative

Attacker objective: Exploit the gap between patched registry state and unpatched runtime workloads to reach exposed production containers.

1. Entry occurs when a vulnerable container image or stale deployment remains live after a fix has already been released and the registry has been updated.
2. Escalation happens when manual deployment paths, cached layers or delayed restarts keep the older image running in production long enough to remain exploitable.
3. Impact is that teams believe the issue is remediated because the registry looks clean, while the running cluster still exposes the vulnerable workload.

Breaches seen in the wild

• Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime state, not artifact state, is the real security boundary in Kubernetes. Registry scanning remains useful, but it does not answer the question that matters during exploitation: what is actually executing right now. The governance failure is treating build-time hygiene as if it were runtime assurance, which collapses as soon as deployments drift or bypass the pipeline. Practitioners should treat live inventory as the authoritative control plane for exposure.

Immutable digest tracking is the named control concept that container teams keep underusing. Tags are operational conveniences, not stable identities, and that makes them poor evidence for audit, incident reconstruction or exposure validation. Digest-level reconciliation is what makes container state provable over time, especially when auditors ask for point-in-time evidence and security teams need to separate patched images from still-running copies. The implication is that identity for workloads must be tied to immutable artifact identity, not mutable labels.

CompOps is a useful shorthand for the real shift here: compliance evidence must fall out of normal operations. If the evidence only appears after a manual scramble, the control is already too slow for cloud-native environments. This is where container governance intersects with identity governance, because service accounts, cluster access and scoped inventory permissions determine whether the platform can observe the live state without overexposing the environment. Teams should make continuous reconciliation part of routine operations, not a special audit project.

Kubernetes drift creates a false sense of remediation that weakens incident response and board reporting alike. A fix published is not a fix deployed, and a clean registry is not a clean cluster. That distinction matters for regulators, auditors and incident responders because the exposure window is defined by runtime reality. Security leaders should treat drift as a governance metric, not just an engineering inconvenience.

Inventory visibility only becomes durable when access is narrow and purpose-built. The article’s emphasis on a read-only service account and a scoped robot user reflects a larger pattern in identity security: the monitoring plane itself must be least privilege. If the inventory path is overbroad, the control that exists to reduce risk becomes a new risk. Practitioners should govern observability credentials with the same discipline they apply to production workloads.

From our research library:

• Red Hat’s Kubernetes Security Report found that nearly 9 in 10 organizations had at least 1 container or Kubernetes security incident in the last 12 months.

What this signals

Live container governance is becoming a state reconciliation problem, not a scanning problem. Teams that still depend on registry scans as their main assurance layer will keep missing the interval where the registry is clean but the workload is not. The operational answer is to make runtime inventory the basis for exposure decisions and to treat cluster visibility as part of the security architecture, not an afterthought.

Inventory credentials need identity governance because observability tools can become privileged actors. A read-only agent still sees enough of the environment to create material exposure if it is over-scoped or reused across clusters. Security teams should model inventory access as a governed identity, with purpose limitation, narrow scope and a clear ownership boundary.

Runtime compliance is the clearer signal now that container patches can lag disclosure by days or weeks. The gap between a fix being available and a workload being updated is where regulatory and operational risk accumulates, so the control objective has shifted from periodic proof to continuous evidence.

For practitioners

• Scope runtime inventory to production namespaces first Start with the namespaces that carry the highest business impact, then expand once the data quality and operational overhead are understood. This keeps the inventory programme focused on the containers most likely to matter during a disclosure event.
• Track workloads by immutable digest Use image digests as the stable identifier for every running container so that point-in-time reports, audit evidence and exposure checks are tied to the actual artifact, not a tag that can change later.
• Treat inventory credentials as privileged read access Run the agent with a dedicated read-only service account and a tightly scoped robot user for the target cluster so that the observability path cannot be repurposed for broader cluster access.
• Reconcile runtime policy against live workloads Evaluate whether admission control or equivalent enforcement can flag non-compliant images after deployment, not just at build time, so drift does not survive until the next manual review.

Key takeaways

• Registry scanning alone does not tell teams whether a container vulnerability is still active in production.
• Runtime drift can persist long enough for exploitation even after a fixed image has been published.
• Continuous cluster inventory and digest-based reconciliation are the controls that change the answer from assumptions to evidence.

Key terms

• Container Drift: Container drift is the gap between the workload state that was approved and the state that actually runs. In practice, drift can include unexpected binaries, altered startup behaviour, or hidden execution paths, and it matters because build-time trust does not guarantee runtime trust.
• Runtime inventory truth: A governance approach in which the authoritative view of APIs comes from observed production behaviour rather than static documentation. It is the basis for aligning discovery, monitoring, and enforcement with the real service landscape.
• Immutable Image Digest: An immutable image digest is a cryptographic identifier for a container image that does not change when tags move or are repointed. It provides stable evidence for forensics and compliance because it links runtime workloads to a specific artifact version rather than a mutable label.
• CompOps: CompOps, or compliance operations, is the practice of generating compliance evidence continuously from normal security operations instead of reconstructing it after the fact. In container environments, that means policy, inventory and reporting work together so auditors can see live state rather than a manually assembled snapshot.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management for practitioners who need to connect identity controls to real operational risk. It is designed for security teams that need a stronger governance model across workloads, service accounts and privileged access paths.