What happens when container images are scanned only at build time?

Build-time scanning alone leaves a blind spot after release. New CVEs are disclosed daily, so an image that looked safe when built can become risky later while still sitting in a registry or running in production. Continuous registry and runtime scanning close that gap by surfacing newly relevant vulnerabilities before attackers exploit them.

Why Build-Time-Only Scanning Misses Real-World Exposure

Build-time scanning is a snapshot, not a state. It tells you what was known about the image when it was assembled, but it does not track what changes after release: newly disclosed CVEs, base image rebuilds, or vulnerable dependencies that become relevant later while the same image is still stored or deployed.

That gap matters because container risk is not static. A clean build can become a high-priority finding without any code change, simply because the vulnerability landscape moved. The practical consequence is that build-time scanning alone can create false confidence in both registry hygiene and production readiness.

NIST SP 800-190 Container Security treats the image, registry, orchestrator, and runtime as separate control points, which is why a one-time scan is incomplete for operational use.

What Changes After the Image Is Built

The core problem is time. Container images are often promoted from build to registry to deployment and then left in service for weeks or months. During that time, vulnerability databases are updated continuously, package maintainers publish fixes, and attackers focus on any newly reachable weakness they can exploit before teams patch or rebuild.

Build-time-only scanning also ignores the fact that an image may be reused in multiple environments. The same artifact can move from dev to staging to production, or remain in a registry as a golden image for future deployments. If you only scan once, you lose visibility into every later decision that makes the image more or less risky.

SLSA is useful here because it pushes teams to treat build integrity and provenance as part of a broader supply-chain control model, not as a substitute for ongoing vulnerability awareness.

The State of Secrets in AppSec is a reminder that static artifacts age badly, especially when credentials or secrets can linger long after the original build context has changed.

Continuous Scanning Closes the Operational Gap

Registry scanning helps catch images that have become vulnerable after they were built, even if no one has redeployed them yet. Runtime scanning adds the last missing layer by checking what is actually running, which is important because a vulnerable image that never launches is not the same risk as one actively serving traffic.

For practitioners, the goal is not just broader coverage but better prioritisation. Continuous scanning lets you separate an image that is merely stale from one that is both stale and exposed in production. That distinction matters because patching, rebuilding, or quarantining an image depends on whether it is dormant, deployed, or externally reachable.

Massive Docker Hub Secrets Leak shows why registry content cannot be treated as harmless inventory, because exposed image content can carry live secrets as well as vulnerable software.

OWASP API Security Top 10 is relevant when containerised services expose APIs, because runtime exposure and access patterns can change the practical impact of a vulnerable image.

Standards & Framework Alignment

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

OWASP Non-Human Identity Top 10 address the attack and risk surface, while 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 — Continuous Monitoring	Image risk changes after build, so continuous monitoring is needed for current exposure.
Recommendation — Extend monitoring to registry and runtime assets so newly relevant image vulnerabilities are detected after release.
CIS Controls v8	7 — Continuous Vulnerability Management	Build-only scanning misses newly disclosed CVEs that appear after the image is built.
Recommendation — Continuously scan deployed and stored container images for newly disclosed vulnerabilities.
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Management	Container images can carry embedded secrets that remain risky after build time.
	NHI-03 — Privilege and Access Control	An image that becomes newly risky can still grant excessive access if deployed unchanged.
	NHI-09 — Visibility and Discovery	Build-only scanning leaves blind spots in registries and running workloads.
Recommendation — Scan images continuously for exposed secrets and rotate any credentials found in artifacts. Reassess image-derived access paths and privileges whenever the vulnerability profile changes. Maintain continuous visibility into stored images and active workloads to catch drift after build.

Practitioner Guidance

What to verify: Confirm that your scanning process tracks three different states, build, registry, and runtime. If all you have is a build pipeline gate, assume your findings will be stale as soon as the image is published.

Decision rule: Treat build-time results as a baseline, not a clearance decision. If the image remains in the registry or production, require re-scanning or continuous monitoring before you consider it low risk.

What good looks like: A new CVE affecting an in-use base layer should surface quickly enough that teams can decide whether to patch, rebuild, or suppress with documented exception handling before attackers have a long window to act.

Practitioner takeaway: Build-time scanning is necessary, but it is only the first checkpoint. If you do not also scan the registry and the running workload, you are managing historical risk, not current exposure.