Most container security programs put real effort into scanning images before they reach a registry, then treat the job as done. That’s a reasonable place to focus, but it leaves something out: what’s declared in a manifest and what’s actually running in a live cluster can drift apart fast. An image gets patched in the registry, but the running pod never gets redeployed. A node holds onto an older layer. Someone deploys manually, or through a pipeline that bypassed the usual gate entirely. None of that shows up in a registry scan, because a registry scan isn’t looking at your cluster. It’s looking at your registry.
Why registry-cluster drift carries real business risk
A registry scan answers “what did we build.” It doesn’t answer “what’s exposed right now,” and those are different questions with different urgency, especially once you look at how long a fix actually takes to reach production.
Red Hat’s own Product Security Risk Report 2025 is a useful, if indirect, illustration of this. Average response times, the time between a CVE becoming public and a fix being released, actually got slower for some severities in 2025: Critical vulnerabilities went from a 7-day average in 2024 to 12 days in 2025, and Low-severity fixes went from 115 days to 204 days. And a released fix isn’t the same as a deployed one. The report’s own account of the 2025 sudo vulnerabilities (CVE-2025-32462 and CVE-2025-32463) makes the point concretely: the first fix shipped just 2 days after public disclosure, but it took 23 days for fixes across the full affected product line to be released, and CVE-2025-32463 was still added to CISA’s Known Exploited Vulnerabilities catalog 3 months after disclosure, meaning it was still being actively exploited well after a fix already existed.
That’s the exact scenario a registry scan can’t see. A fixed image sitting in your registry tells you nothing about which of your running pods are still on the older, vulnerable versions during the days or weeks it takes to roll out and apply changes. This is a structural problem, not a matter of scanning more often. A registry is a catalog. A cluster is a running system that changes continuously: pods get rescheduled, images get pulled from caches, deployments happen outside the pipeline you’re watching. Fixing that means giving your security platform a way to see the cluster directly, not just the registry it’s fed from.
This is becoming a compliance problem, not just an operational one. Under the EU Cyber Resilience Act, organizations will be required to report actively exploited vulnerabilities to ENISA within 24 hours of discovery once that obligation takes effect in September 2026. An organization that can’t identify which of its running production containers are affected by a newly disclosed exploit within hours has already missed that window, regardless of whether the vulnerability was caught in a scan at some earlier point. Anchore’s whitepaper on making Kubernetes continuously audit-ready goes deeper on this shift, from compliance as a periodic paperwork exercise to what it calls Compliance Operations, or CompOps: treating compliance as a continuous, automated capability rather than something reconstructed by hand when an auditor asks.
Download our latest Whitepaper on CompOps – how we can make Kubernetes continuously audit ready.
How the Kubernetes inventory agent sees what’s actually running
helm repo add anchore https://charts.anchore.io
helm install <release-name> -f <values.yaml> anchore/k8s-inventoryThe agent polls the Kubernetes API directly to determine which images are actually scheduled and running across the namespaces you configure it to watch. That’s a meaningfully different data source than a registry: it reflects the cluster’s actual state at the moment it’s polled, not a snapshot from whenever an image was last pushed.
Create a values file like the example below and apply it:
k8sInventory:
# Path should not be changed, cluster value is used to tell Anchore which cluster this inventory is coming from
kubeconfig:
cluster: <unique-name-for-your-cluster>
namespaceSelectors:
include: ["namespace1","namespace2"]
exclude: []
anchore:
url: <URL for your Anchore Deployment>
# Note: recommend using the inventory-agent role
user: <user>
password: <password>
account: <account>
inventory_ingest_overwrite: [true or false] If true, runtime images are overwritten as new images are reported to the system, by default its 60 seconds.
inventory_ttl_days: 7 (Will delete runtime data for images that haven't been seen in 7 days)Access matters here more than it does almost anywhere else in the stack. The agent runs as a read-only service account, and Anchore recommends configuring a dedicated robot user scoped specifically to the account tracking that cluster’s inventory, rather than reusing broader credentials. An agent with cluster-wide visibility into what’s running is a meaningful thing to have access to, so it’s worth treating the credential itself as seriously as you’d treat any other read access to production.
Once the agent is reporting, you activate inventory tracking per cluster and namespace rather than turning it on blanket-wide by default. That’s a real operational decision, not a formality: scanning every namespace in every cluster is a different resourcing commitment than scoping to production namespaces first, and most teams are better served starting narrow and expanding once they’ve seen what the data actually looks like.
From there, the payoff is in the reconciliation. Anchore Enterprise ties each running image back to its known vulnerabilities and CVSS scores, and surfaces that directly in context of what’s deployed, not as a separate report you have to cross-reference by hand. And because policy evaluation runs against runtime data the same way it runs against build-time data, you can enforce, not just observe: flagging, or optionally blocking, workloads that don’t meet policy even after they’re already running using Kubernetes Admission Controller.
One detail worth calling out: the agent identifies images by their immutable digest, not their mutable tag. A tag like nginx:latest can point to a different image entirely from one day to the next, so tracking by tag alone breaks the moment someone pushes an update. Digest-level tracking stays accurate even after that happens, which matters when you’re asked to reconstruct exactly what was running on a specific past date. Anchore Enterprise can generate a point-in-time inventory report for any date within its retention window, which is a meaningfully different answer than “here’s our vulnerability management process” when an auditor’s actual question is closer to “show me the SBOM and vulnerability status of every image running in production last Tuesday.”
The outcome: one live inventory, continuously reconciled
Go back to the original problem: a registry scan tells you what you built, and says nothing about what’s actually exposed in production right now. That’s exactly the window Red Hat’s own data illustrates, the days or weeks between a fix being released and a fix being deployed everywhere it needs to be, and it’s not something you close by scanning the registry more often.
The technical outcome is a live, queryable record that reconciles what’s running against what’s vulnerable, refreshed continuously rather than reconstructed by hand during an incident. The business outcome is being able to answer “are we affected” the moment a new CVE lands, instead of coordinating a multi-team scramble across every cluster to find out, and having that same evidence ready by default the next time an auditor or regulator asks. These are easy to gather metrics that feed into incident response plans. That’s the practical version of CompOps: not a new tool bolted on before an audit, but compliance evidence that falls out of normal operations as a byproduct.
Infoblox shows what this looks like at scale, even if their story is more about keeping pace with production than catching drift specifically. Their product security team was covering 150 applications built by 600 engineers on infrastructure running through Amazon EKS, and a 15-person security team couldn’t keep up with manual vulnerability review across an environment moving that fast. After integrating Anchore Enterprise into their pipeline and registry, and giving engineers self-serve access to scan their own code as they wrote it, Infoblox’s product security team cut the time spent on vulnerability detection tasks by 75%, while maintaining FedRAMP Moderate, SOC 2, StateRAMP, and ISO 27001 certifications across that same fast-moving EKS environment.
This is the same runtime visibility Anchore Enterprise customers rely on to answer “what’s actually running” across their own clusters today. If you’re already running Anchore Enterprise, our Kubernetes inventory quickstart walks through the full setup, from agent deployment to policy enforcement against live workloads. If you’re evaluating how this would work across your own clusters, request a demo and bring your actual environment to the conversation.
This is the second post in this series. Post 1 covered what your SBOM inventory misses if it only covers containers. Next up: why “scan when a CVE drops” is too slow now, and what querying an existing inventory buys you instead.
