Because vulnerabilities do not stop mattering after code is built. Scanning only in the pipeline misses drift, late exposure, and runtime conditions in production. A combined approach helps teams catch problems earlier, confirm what is actually running, and keep remediation aligned with deployment reality across fast-moving DevOps environments.
Why CI/CD scanning alone is not enough
Container vulnerability scanning has to follow the image from build to runtime because the risk surface changes after the pipeline finishes. A clean build does not guarantee a clean deployment: base images age, tags drift, configuration changes alter exposure, and clusters may run a different image digest than the one that was scanned. That is why pipeline scanning and live cluster visibility solve different parts of the same problem.
In CI/CD, scanning answers whether the artifact being built contains known issues before it is published. In Kubernetes, scanning and inspection answer whether the running workload matches what was approved, what namespaces and image sources it is actually using, and whether an apparently acceptable image has become risky through environment-specific exposure or delayed patching.
What live Kubernetes scanning adds that the pipeline cannot see
Live environments introduce drift, and drift is often the reason the original scan becomes stale. A workload can be redeployed with a new base layer, admitted from an alternate registry, or launched from a mutable tag that no longer points to the same content. Runtime scanning helps confirm the deployed state, not just the intended state, which matters when teams need evidence about what is actually consuming risk in production.
Operationally, this also improves prioritisation. A vulnerability inside an image that never reaches production is less urgent than the same vulnerability in a namespace with internet exposure, elevated permissions, or high-value data access. The live environment provides the context needed to separate theoretical exposure from active exposure.
For teams that treat build security as a supply-chain control, NIST SP 800-190 Container Security remains a useful reference because it frames container risk across images, registries, orchestrators, and runtime conditions.
Why the best practice is a combined model
The strongest operating model is shift-left plus runtime validation. Pipeline scanning catches issues before release, which is the cheapest time to fix them. Live scanning catches what the pipeline cannot know with certainty, including post-build drift, delayed exposure, and cluster-specific misconfiguration. Together, they reduce blind spots in fast-moving DevOps environments where images are built once and deployed many times.
The same logic applies to remediation workflows. If teams rely only on CI/CD findings, they may overstate risk for images that never shipped and understate risk for workloads that were redeployed later from a changed source. If they rely only on runtime findings, they miss the chance to stop vulnerable artifacts before they enter the cluster at all.
That is also why image provenance and artifact integrity matter alongside scanning. SLSA helps teams reason about build integrity, while runtime validation verifies that the deployed container still matches the security assumptions made at release time.
Risk and Threat Considerations
Container vulnerability risk is not static. Attackers benefit when organisations scan once at build time and then assume the result still reflects production. That assumption breaks down when mutable tags, registry changes, delayed patch cycles, or cluster drift let a workload diverge from what was originally assessed.
Failure mechanism: A vulnerable image, altered deployment, or stale tag bypasses the original pipeline decision, then remains active in Kubernetes long enough to be exploited or to increase blast radius through network reachability, exposed services, or privilege carried by the pod.
Impact: Teams lose visibility into the real attack surface, remediation becomes misprioritised, and an apparently low-risk build can become a production exposure. In practice, this can turn a one-time scan result into a false sense of safety.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | Directly supports scanning both build artifacts and running workloads. |
| CM-8 — System Component Inventory | Kubernetes scanning depends on knowing what is actually deployed. | |
| SI-2 — Flaw Remediation | Explains why discovered container vulnerabilities must be tracked through to remediation. | |
| Recommendation — Scan images and live workloads continuously, not only during build. Maintain an accurate inventory of deployed container components and versions. Prioritise remediation based on runtime exposure and deployment impact. | ||
| OWASP ASVS | V13 — Configuration | Runtime container exposure often changes through configuration and deployment drift. |
| Recommendation — Verify deployment configuration as part of vulnerability assessment. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Combines build-time and runtime vulnerability discovery into one operational control. |
| Recommendation — Continuously assess vulnerabilities across images, registries, and deployed containers. | ||
Practitioner Guidance
What to verify: Check that the digest scanned in CI/CD is the same digest admitted to the cluster, and treat mutable image tags as an exception condition unless you can prove strong provenance.
What to measure: Track the gap between image publication, deployment, and vulnerability remediation. If the time between those steps is long, runtime scanning and revalidation become materially more important.
Common mistake: Treating a passing pipeline scan as proof that production is safe. A clean build only tells you about one point in time, not the state of the running workload.
Practitioner takeaway: Use CI/CD scanning to block bad artifacts early, then use Kubernetes-aware scanning to confirm what is actually running and whether deployment reality has changed the risk profile.
Related resources from NHI Mgmt Group
- Why do CI/CD pipelines change the risk profile of vulnerability scanning?
- What do teams get wrong about container vulnerability management in CI/CD pipelines?
- How can teams use relationship data from CI/CD and build pipelines to support vulnerability response?
- Why do private container images increase NHI risk in CI/CD environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
