Pre-deployment scanning checks images before they are shipped, which helps catch known issues early but misses problems that appear in deployed workloads or in tools already running in the cluster. Continuous runtime scanning enumerates live deployed images through the Kubernetes API and keeps time-ordered results. That makes it better suited for finding exposure that only exists after deployment.
Why pre-deployment and runtime scanning answer different questions
Pre-deployment scanning is a release gate. It checks container images before they are shipped so teams can catch known issues early, reduce rework, and avoid deploying clearly unsafe artifacts. Continuous runtime scanning is an operational visibility control. It inspects what is actually running in the cluster, so it can surface exposure that only appears after deployment, including image drift, unplanned rollout changes, and workloads that were not present when the image was originally reviewed.
The practical difference is that pre-deployment scanning evaluates a build artifact, while runtime scanning evaluates live state. In Kubernetes, those are not the same thing because the deployed workload can differ from the image that was approved, and the security picture can change after admission through new images, tags, replicas, or supporting components.
Where each approach is strongest
Pre-deployment scanning is strongest when your goal is to stop known vulnerability patterns before they reach production. It is best suited to build pipelines, image registries, and release approval, and it works well when teams want fast feedback for developers. Runtime scanning is stronger when the question is, “What is exposed right now?” It aligns better with operational reality because it can enumerate live deployed images through the Kubernetes API and keep results ordered over time.
That time-ordered view matters. If you are investigating whether a vulnerable image is actually present in the cluster, whether it was introduced by a recent deployment, or whether a fix has propagated everywhere, runtime findings provide the deployment context that pre-deployment checks do not have. For containerised environments, that is often the difference between a theoretical issue and a confirmed exposure.
- Use pre-deployment scanning to prevent obviously risky images from entering the cluster.
- Use runtime scanning to verify what is actually deployed and to detect exposure introduced after approval.
- Treat the two controls as complementary, not interchangeable.
For broader container security guidance, NIST SP 800-190 Container Security is the most direct external reference for image, registry, orchestrator, and runtime risk. For teams thinking about the lifecycle side of this problem, NHIMG’s NHI Lifecycle Management Guide is useful because it connects visibility, rotation, and offboarding to the broader problem of keeping deployed identities and artifacts under control.
Risk and Threat Considerations
The risk is not just that a vulnerable image exists, but that pre-deployment-only coverage can leave a gap between approval and actual exposure. In Kubernetes, drift can be introduced by redeployments, tag reuse, side-loaded changes, or components that were not in scope when the image was scanned. Runtime scanning reduces that blind spot by showing whether a vulnerable image is present in a live workload, not merely whether it passed a gate earlier.
Failure mechanism: A pre-deployment check approves an image, but the running cluster later exposes a different image, a different version, or a workload that was never reviewed in the build pipeline. The control fails because it does not observe the deployed state.
Impact: Known vulnerabilities can remain exploitable in production even though the pipeline appeared clean, and security teams may miss active exposure until after abuse or incident response begins.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — The Network Is Monitored To Detect Potential Cybersecurity Events | Runtime scanning supports continuous visibility into live cluster exposure. |
| ID.AM-02 — Software Platforms and Applications Are Inventoried | Continuous scanning helps maintain an accurate view of deployed software in Kubernetes. | |
| PR.DS-01 — Data-at-Rest Is Protected | Container image review can prevent deployment of software that would expose sensitive systems. | |
| Recommendation — Monitor live Kubernetes workloads to detect vulnerable images after deployment. Keep the deployed application inventory current by scanning live workloads. Block vulnerable software before it reaches production data paths. | ||
| CIS Controls v8 | 8.2 — Inventory Software Assets | Runtime scanning enumerates deployed images and reveals what is actually running. |
| 7.1 — Establish and Maintain a Vulnerability Management Process | Both scanning modes support identifying and prioritising vulnerabilities at different stages. | |
| Recommendation — Inventory running container images continuously to catch drift from approved builds. Use pre-deployment and runtime findings together in the vulnerability management workflow. | ||
Practitioner Guidance
What to verify: Confirm whether your runtime scanner is reading live cluster state from the Kubernetes API and whether it keeps historical findings long enough to support incident triage and change review. If it only reports a point-in-time snapshot, you lose much of the value of continuous monitoring.
Decision rule: If the question is “should this image be released?”, pre-deployment scanning is the right control. If the question is “what is exposed in the cluster now?”, runtime scanning is the right control. In mature programs, you need both because one controls release risk and the other controls drift and post-deployment exposure.
Practitioner takeaway: Use pre-deployment scanning to block bad builds, but rely on continuous runtime scanning to answer the harder operational question: what vulnerable software is actually live after deployment and change.
Related resources from NHI Mgmt Group
- What is the difference between pre-deployment scanning and runtime protection?
- What is the difference between pre-deployment CSPM scanning and continuous cloud posture monitoring?
- What is the difference between runtime detection and posture scanning for Kubernetes security?
- What is the difference between image scanning and runtime protection in Kubernetes security?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
