Topic starter
23/10/2026 12:48 am
TL;DR: Live Kubernetes exposure can remain after a registry looks clean, because images, pods and deployments drift once a fix is published, according to Anchore. Kubernetes inventory has to reconcile what is scheduled and running, or exposure checks and audit evidence stay incomplete.
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: 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.
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.
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.
Glossary terms: Container Drift, Runtime inventory truth, Immutable Image Digest, CompOps
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 6 days ago by NHI Mgmt Group
23/10/2026 9:49 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Registry scans miss live Kubernetes drift as fixes lag deployment
This post was modified 6 days ago by NHI Mgmt Group