Join our Newsletter — 33% off our NHI Course

Should teams scan container images in the registry or at runtime?

For most multi-cloud estates, registry-based scanning is the better governance default because it centralises inventory, reduces duplicate work, and avoids distributing privileged agents into every runtime. Runtime scanning still has niche value, but it should be the exception, not the primary control.

Why registry scanning is usually the governance default

Registry scanning fits the governance problem better when teams need a repeatable, auditable view of what exists before it runs. It centralises inventory, lets security teams prioritise high-risk images once, and avoids pushing inspection logic into every cluster, host, or node pool. That makes it easier to standardise policy across multi-cloud estates.

It also aligns better with the control question most teams actually face: which images are approved, which are vulnerable, and which should be blocked before deployment. Scanning at registry time gives you a stable decision point, while runtime scanning tends to become a supplemental signal for drift, unexpected execution, or late discovery.

For image-origin risk and leaked credentials in registries, secrets hidden inside container images and large-scale Docker Hub secret exposure show why registry review catches problems before they spread into many deployments.

What runtime scanning is actually good for

Runtime scanning is not useless, but it answers a different question. It is strongest when you need to observe the running environment, confirm that the deployed workload matches expectations, or look for artefacts that only appear after startup. That makes it more of a detection and validation layer than the primary image governance control.

In practice, runtime approaches are most defensible for narrow, high-value cases: workloads with high drift risk, environments where image provenance is weak, or incident-response investigations where you need to determine what actually executed. They are weaker as the primary prevention layer because they arrive after deployment and usually require more operational footprint.

The risk of over-relying on runtime scanning is that teams mistake visibility for prevention. A runtime control can tell you that a bad image is live, but it may not stop the initial rollout, and it may add agent overhead, permissions, and complexity across every cluster.

Container guidance from NIST SP 800-190 Container Security treats image, registry, orchestrator, and runtime as distinct control points, which is why registry scanning and runtime monitoring should be layered rather than conflated.

What good container image governance looks like in practice

A sensible control model is to make registry scanning the default gate, then use runtime scanning only where it adds distinct value. That means scanning on push or before promotion, attaching results to the image record, and making deployment decisions from the central system of record rather than from each runtime environment.

Use runtime inspection selectively when the business need is tied to live state, such as verifying that a sensitive workload is not launching unexpected processes or detecting a late-binding dependency that could not be resolved earlier. The key judgement is whether the runtime signal changes the decision, or merely duplicates what the registry already told you.

For teams that manage access to images, registries, and deployment pipelines as part of broader platform governance, the control should also preserve clear ownership of who can publish, approve, promote, and run an image. When those boundaries blur, scanning becomes noise instead of enforcement.

What to verify: Confirm that every image is scanned at the registry before promotion, that scan results are retained with the image metadata, and that the deployment pipeline can block known-bad images without waiting for runtime detection.

Decision rule: If the question is “should this image be allowed into production?”, use registry scanning as the primary control; if the question is “what is this workload doing right now?”, use runtime monitoring as a secondary control.

Practitioner takeaway: Treat registry scanning as the authoritative governance checkpoint and runtime scanning as an exception path for live-state visibility, not as a substitute for image-level control.

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, NIST CSF 2.0, CIS Controls v8 and NIST SP 800-190 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST SP 800-53 Rev 5 SI-2 — Flaw Remediation Container image scanning identifies known flaws before deployment.
CM-8 — System Component Inventory Registry scanning depends on a stable inventory of container images and versions.
AU-2 — Event Logging Runtime scanning and image promotion decisions both depend on auditable control evidence.
Recommendation — Scan images before promotion and block releases with unremediated high-risk findings. Maintain a central image inventory and attach scan results to each released artifact. Log scan outcomes and deployment decisions so runtime findings can be traced to released images.
NIST CSF 2.0 PR.IP-1 — Baseline Configuration Registry scanning supports baselining approved images before they run.
Recommendation — Define approved image baselines and gate promotion against them before runtime.
CIS Controls v8 CIS-4 — Secure Configuration of Enterprise Assets and Software Image scanning helps enforce secure software configuration before deployment.
Recommendation — Use registry scanning to enforce approved image configurations before rollout.
NIST SP 800-190 Container Security The topic directly concerns image, registry, orchestrator, and runtime container controls.
Recommendation — Apply container security guidance to separate registry governance from runtime monitoring.