What is the difference between scanning before deployment and scanning running Kubernetes environments?

Pre-deployment scanning checks artifacts such as code, containers, manifests, and infrastructure templates before they reach production. Runtime scanning checks live clusters and resources after deployment to catch issues introduced by state changes, new workloads, or configuration drift. Both are necessary because cloud native risk exists across the build pipeline and in the operating environment.

Why pre-deployment scanning and runtime scanning answer different questions

Pre-deployment scanning is about preventing bad artifacts from entering the cluster in the first place. It inspects code, container images, manifests, Helm charts, and infrastructure templates before deployment, so teams can catch vulnerable dependencies, insecure defaults, and obvious misconfigurations while the change is still cheap to fix. Runtime scanning answers a different question: what is actually happening in the live Kubernetes environment right now?

The practical difference is timing and evidence. Pre-deployment tools work against intended state, while runtime tools examine observed state, including active workloads, cluster objects, permissions, and configuration drift. That matters because Kubernetes risk often emerges after deployment, when new namespaces, controllers, service accounts, or manual changes create exposure that did not exist at build time. NHI lifecycle management is a useful analogue for this shift from planned state to operational state.

Neither approach is sufficient on its own. A clean image scan does not prove the running cluster is safe, and a healthy runtime snapshot does not make an unsafe artifact acceptable. The most reliable programme treats pre-deployment scanning as shift-left prevention and runtime scanning as continuous verification and drift detection, with each feeding a different part of the security decision.

What each scanning stage tends to catch

Pre-deployment scanning is strongest at finding issues embedded in software and deployment assets before they become live risk. That includes vulnerable libraries, exposed secrets in images or manifests, insecure Kubernetes settings, excessive privileges defined in YAML, and infrastructure-as-code problems that would otherwise be repeated across environments. It is also the right stage to reject artifacts that are clearly non-compliant before they can create operational blast radius. For container-focused environments, NIST SP 800-190 Container Security is directly aligned with image, registry, and orchestrator risk.

Runtime scanning is stronger at finding conditions that only exist after scheduling and reconciliation. Examples include privileged pods created by controllers, workload changes made outside the intended pipeline, service exposure created by cluster networking, secrets mounted into unexpected namespaces, and drift between declared policy and actual running resources. It can also reveal whether controls are still effective after autoscaling, redeployment, or emergency changes. That live view is especially important in Kubernetes, where the control plane continually reconciles state and the environment can change without a new build.

The distinction is not just operational convenience. It changes the failure mode you are trying to see. Pre-deployment scanning focuses on defects in artifacts and definitions. Runtime scanning focuses on emergent exposure caused by execution, orchestration, or environment drift. In a mature programme, the findings are related but not interchangeable.

How practitioners should combine both in Kubernetes

The most effective pattern is to use pre-deployment scanning as a gate and runtime scanning as a detector. If the build pipeline can stop bad images, manifests, or templates early, the live cluster sees fewer defects. If runtime scanning is watching for drift, privilege escalation, unexpected workloads, and policy violations, it can catch the cases that slipped through or appeared later through manual intervention.

What good looks like is a clear division of labour. Pre-deployment checks should own artifact quality, policy conformance, and promotion decisions. Runtime checks should own visibility into live resources, exceptions, and changes that occur after deployment. When both are wired into incident response, a team can answer two questions quickly: did we ship something unsafe, and did the running environment diverge from what we approved? The operational value is highest when findings flow into the same triage process instead of living in separate tools.

One practical caution is false confidence from “passing” scans. A pre-deployment pass only says the artifact looked acceptable at the moment it was built. A runtime pass only says the cluster looked acceptable when it was observed. Kubernetes changes too quickly for either result to be treated as permanent truth, so the control objective is continuous assurance, not one-time validation.

Risk and Threat Considerations

The main risk is believing that build-time assurance covers runtime reality. In Kubernetes, attackers and misconfigurations both exploit the gap between declared state and running state, especially when secrets, RBAC, admission controls, or manual fixes create drift after deployment.

Failure mechanism: A vulnerable or overpermissive artifact can be introduced before deployment, or a safe deployment can become unsafe after rollout because a controller, operator, or human change alters the live cluster state.

Impact: The organisation can end up with exposed workloads, privilege abuse, secret leakage, lateral movement paths, or configuration drift that persists even though the original pipeline checks appeared to pass.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-190, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-190	Container Security	Covers container image, registry, and orchestrator risks central to pre-deployment and runtime scanning.
Recommendation — Apply container security guidance to inspect images, registries, and runtime orchestration for drift and exposure.
NIST CSF 2.0	PR.DS-01 — Data-at-rest is protected	Scanning Kubernetes artifacts and live clusters helps prevent exposed secrets and sensitive data in containerized workloads.
	DE.CM-03 — Personnel, devices, software, and systems are monitored for anomalous activity	Runtime scanning depends on monitoring live clusters for drift and unexpected workload behavior.
Recommendation — Protect sensitive data in manifests, images, and mounted secrets before and after deployment. Monitor running clusters for unexpected changes, new workloads, and policy drift.
NIST SP 800-53 Rev 5	CM-2 — Baseline Configuration	Pre-deployment scanning validates artifacts against approved baselines before release.
	CM-6 — Configuration Settings	Runtime scanning checks live configuration against required security settings and drift.
Recommendation — Establish and verify approved Kubernetes baselines before deployment. Continuously validate live cluster settings against required secure configurations.

Practitioner Guidance

What to prioritise: Treat pre-deployment scanning as a release-quality control and runtime scanning as a cluster-integrity control. If you only have maturity for one side first, start with the stage where your environment changes most often, because that is where silent drift will accumulate fastest.

What to verify: Confirm that pre-deployment rules actually inspect the Kubernetes-specific objects that create risk, not just container images. Then verify that runtime tooling has visibility into live workload state, cluster configuration changes, and the resources most likely to drift under automation.

Practitioner takeaway: The right control model is not “which scan is better,” but “which state are we trusting,” because Kubernetes security depends on checking both the intended configuration and the live environment that may have already moved on.