Kubernetes drift: what teams are missing between registry and cluster?

TL;DR: Registry scans cannot show what is actually running in Kubernetes, according to Anchore, because images, pods and deployments drift after a fix is published, leaving a window where vulnerable workloads remain exposed even though the registry looks clean. The practical shift is from build-time scanning to continuous runtime inventory and reconciliation.

Editorial analysis by NHI Mgmt Group, based on content published by Anchore: “Your Kubernetes cluster is running images your registry scan never checked”.

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.

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.

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.

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.

Practitioner guidance

• 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.
• 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.

Bottom line: Registry scanning alone does not tell teams whether a container vulnerability is still active in production.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →