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.
Why Registry-Only Scanning Misses the Real Control Point
Registry scanning is a supply-side check: it tells you whether an image in storage looks acceptable at scan time. That is useful, but it does not prove the running workload is using that image, or that the live pod has not drifted, been rescheduled, or retained an older vulnerable layer. In practice, the control boundary is the workload, not the registry.
That distinction matters most in Kubernetes, where an image can be rebuilt, rescanned, and pushed cleanly while an older replica keeps running the vulnerable version until it is restarted or replaced. A registry-only view can therefore create a false sense of remediation, especially when deployment speed, autoscaling, or manual changes keep live state ahead of registry state.
For container programmes, Container Security Guide is the broader control baseline because it ties image controls to runtime isolation, orchestration, and host hardening rather than treating scanning as a standalone answer.
What Control Coverage You Lose Without Runtime Validation
The first gap is exposure validation. If you only scan registries, you cannot reliably answer whether a vulnerable image is still executing in a cluster, whether multiple namespaces are affected, or whether a patched artifact has actually displaced the old one. The result is a weak control that measures build hygiene but not active exposure.
The second gap is operational trust. Incident response depends on knowing what is live, where it is live, and whether it has been touched since deployment. A registry scan cannot tell you which pods are still in memory, which nodes are hosting them, or whether the vulnerable workload is reachable through service endpoints right now. That is why runtime inventory and workload state checks matter as much as image hygiene.
The third gap is evidence quality. Audit evidence built only from registry results can show that images were reviewed, but not that vulnerable workloads were removed from production. When the question is “what was protected in production at a point in time,” you need runtime attestations, deployment records, and cluster state evidence, not just a passing scan report.
Runtime evidence is strongest when paired with NIST SP 800-190 Container Security, which explicitly treats image, registry, orchestrator, and runtime risk as separate control surfaces.
How to Close the Gap Between Images, Pods, and Proof
Modern container security has to verify both artifact integrity and execution state. Image scanning should happen before deployment and again when images are promoted, but it should be followed by runtime checks that confirm the running pod matches the approved image digest, policy, and namespace placement. If the runtime picture is missing, the control is incomplete.
In Kubernetes, that usually means checking the workload inventory, deployment manifests, admission controls, and node-level runtime telemetry together. You are looking for drift between what the registry says is safe and what the cluster is actually executing. If the two disagree, the runtime state wins, because that is what attackers and outages can affect.
When teams want a broader view of buying or evaluating controls, the Container Security Buyer’s Guide helps map where image scanning ends and where runtime protection and Kubernetes posture begin.
Risk and Threat Considerations
Registry-only scanning creates a blind spot that adversaries can exploit by keeping vulnerable containers alive after the image has been fixed upstream. The operational risk is not that the scan is wrong, but that it describes the artifact lifecycle while the attack surface is defined by the running workload.
Failure mechanism: A vulnerable pod continues to run from an already-pulled image, or an old replica remains active after a clean image is published, so the registry looks remediated while exposure persists in the cluster.
Impact: Teams overstate remediation, miss live exposure during incident response, and produce audit evidence that does not prove the vulnerable workload was actually removed from production.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5, NIST SP 800-190 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Helps govern live workload and deployment access paths that keep vulnerable containers running. |
| Recommendation — Audit and remove standing deployment access that can keep stale workloads active. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | Inventory of running containers is required to validate exposure beyond registry state. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Audit evidence must show runtime state, not just image scan results, to prove remediation. | |
| Recommendation — Maintain an inventory that distinguishes approved images from live running workloads. Correlate scan findings with runtime logs and deployment records before closing exposure. | ||
| NIST SP 800-190 | Container Security | Container security guidance treats image, registry, orchestrator, and runtime risk as distinct surfaces. |
| Recommendation — Apply runtime controls alongside registry scanning to validate what is actually executing. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software | Runtime monitoring is needed to detect vulnerable or unexpected container execution in production. |
| Recommendation — Monitor live workloads so exposure cannot hide behind a clean registry result. | ||
Practitioner Guidance
What to prioritise: Treat registry scanning as one input to release gating, not as a production assurance control. The key question is whether the running workload matches the approved artifact, not whether the registry contains a clean copy.
What to verify: Confirm that your detection path can answer three questions together: which image was approved, which digest is running, and which pods are still live after a rebuild or redeploy. If you cannot answer all three, you do not have a complete exposure picture.
Common mistake: Reporting “no vulnerable images found” while never checking whether vulnerable pods still exist. That is the classic registry-to-runtime mismatch, and it is where false confidence enters the programme.
Practitioner takeaway: The control objective is continuous alignment between approved image state and live workload state, because only that proves exposure has actually been removed.