Pre-deployment scanning checks images before they ship, so teams can catch known issues before release. Production scanning checks what is actually running, which matters when workloads change, drift, or bypass earlier assumptions. Used together, the two controls improve coverage by linking build-time assurance with runtime visibility and remediation.
How pre-deployment scanning and production scanning differ
Pre-deployment scanning answers a build-time question: what risks are present in the image or artifact before it becomes part of a release? It is strongest when you want to block known issues early, reduce rework, and keep vulnerable content from entering the environment. Production scanning answers a runtime question: what is actually executing now, and has anything changed since the artifact was approved?
The practical difference is coverage. Pre-deployment scanning is a gate on what should ship; production scanning is a check on what is really running. That makes the two controls complementary rather than interchangeable, because drift, emergency changes, and deployment exceptions can all create a gap between the approved image and the live workload. NIST SP 800-190 Container Security describes the image, registry, orchestrator, and runtime layers as distinct control points for that reason.
In container environments, the same image can be rebuilt, retagged, overridden at runtime, or supplemented with mounted content and injected configuration. Pre-deployment scanning is therefore a good assurance mechanism, but it does not tell you whether the running container still matches what was scanned. Production scanning closes that gap by giving operators visibility into live state, including drift and exposure that emerged after deployment.
Why each scan catches a different class of problem
Pre-deployment scanning is best at known-good release hygiene. It catches exposed packages, vulnerable libraries, hardcoded secrets embedded in images, and misconfigurations before they reach users. A strong example of why this matters is Massive Docker Hub Secrets Leak, which shows how secrets hidden in container images can persist long before runtime monitoring ever has a chance to see them.
Production scanning is best at detecting what the build process could not know. It can surface hotfixes applied directly to running instances, unexpected packages added after startup, compromised content, or containers that are no longer aligned with the approved artifact. It also helps when multiple clusters, autoscaling, or orchestration workflows make the deployed state more dynamic than the release pipeline assumed. In practice, this is where runtime inspection and NHI Lifecycle Management Guide become operationally relevant, because ownership, rotation, visibility, and decommissioning problems often show up after launch rather than before it.
The strongest operating model is layered. Pre-deployment scanning reduces the volume of bad content that can be deployed, while production scanning detects the subset of issues that only become visible once the container is live. That is why runtime controls are a visibility and remediation layer, not just another quality gate.
When to rely on each control and how to combine them
Pre-deployment scanning should be treated as the default preventative control, especially in CI/CD pipelines where release decisions are still reversible. Production scanning should be treated as a compensating and corroborating control, especially where runtime drift, shared images, delayed patching, or manual interventions are realistic. If you have to choose one, pre-deployment scanning generally reduces more risk per unit of effort, but only production scanning can confirm whether the live workload still matches the approved baseline.
In mature environments, the useful question is not which one is better, but what each one proves. Pre-deployment scanning proves the artifact was acceptable at the point of release. Production scanning proves the live system remains within expected bounds after release. Teams get the most value when they compare the two results and treat mismatches as a sign of drift, exception handling, or control bypass.
Practitioner takeaway: Use pre-deployment scanning to stop bad images from shipping, and production scanning to catch drift and runtime reality; the control pair only works when you compare approved artifact state with live workload state and act on mismatches.
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 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | Container scanning is used to find known flaws before release and after deployment. |
| CM-2 — Baseline Configuration | The question hinges on comparing approved build state to live runtime drift. | |
| SI-7 — Software, Firmware, and Information Integrity | Production scanning helps confirm runtime integrity against tampering or unauthorized change. | |
| Recommendation — Scan images and running workloads for known flaws, then remediate mismatches promptly. Establish and verify approved container baselines before allowing production drift. Validate runtime integrity and investigate containers that diverge from the scanned artifact. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Container scanning differs by whether it checks the release artifact or the running configuration. |
| Recommendation — Control container configuration changes so runtime state remains traceable to approved builds. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | The distinction between shipped images and running containers is a secure-configuration issue. |
| Recommendation — Harden and monitor container configurations so drift is detected and corrected quickly. | ||
Related resources from NHI Mgmt Group
- What is the difference between scanning before deployment and scanning running Kubernetes environments?
- What is the difference between scanning container images at rest and prioritising running containers?
- What is the difference between pre-deployment scanning and runtime protection?
- What is the difference between build-time scanning and deployment-time policy checks?
