They should be scanned to find vulnerabilities, malware, misconfigurations, and embedded secrets before deployment or release. Scanning images and build artefacts helps catch problems introduced by base layers, dependencies, and build output that source code reviews may miss. Defenders should treat failed scans as release-blocking signals and verify both the final image and anything packaged into it.
Why scan what gets shipped, not just the source tree?
Container images and build artefacts can carry risk that never appears in application source. A clean repository can still produce a risky release if the base image is outdated, a dependency bundle contains a known flaw, or the build pipeline packages in files that should never reach production. That is why release-time scanning is a separate control, not a substitute for code review.
Scanning the final artefact is the way to verify what will actually run, including layers added by the base image, compiler output, vendored packages, binaries, and other packaged content. NIST’s NIST SP 800-190 Container Security treats image, registry, orchestrator, and runtime risk as distinct concerns, and that separation matters because defects often enter after the developer has finished writing code.
What scanning is meant to catch before release
The most immediate value is finding vulnerabilities in the contents of the image or artefact before they are promoted. That includes vulnerable operating system packages, inherited library flaws, exposed services, unsafe permissions, and artefacts built from untrusted or stale inputs. Scanning is also a way to identify misconfigurations such as dangerous file permissions, unexpected setuid binaries, or insecure defaults that would be hard to spot by reading source alone.
It is equally important for detecting embedded secrets. Keys, tokens, certificates, and credentials sometimes end up in layers, packaged config files, or compiled assets even when the application code looks clean. NHIMG’s Secrets in Docker Hub images (RWTH Aachen study) and Massive Docker Hub Secrets Leak both show why image-layer inspection matters: secrets can persist in published artefacts long after the source commit has been cleaned up.
Scanning is also a provenance check in practice. The question is not only “does this artefact contain a vulnerability?” but also “does it contain the right thing, built the right way, from the right inputs?” That is why image scanning is often paired with signature validation and SBOM review in release pipelines, especially when third-party layers or generated build output are involved.
What to verify when a scan fails
A failed scan should be treated as a release-blocking signal until someone confirms whether the finding is real, exploitable, and present in the exact artefact that will be deployed. That means checking whether the issue is in the final image, in a transient build stage, or in a packaged file that should have been excluded. It also means separating inherited base-image issues from problems introduced by your own build process, because remediation ownership is different in each case.
Where the artefact contains an exposed secret, the response is broader than deleting the file and rescanning. The secret may already have been copied into registries, caches, logs, or downstream environments, so teams should assess where else that value may have propagated and whether it can still authenticate anywhere. NIST SP 800-190 is useful here because it forces the review to include registry and distribution paths, not just the local build output.
For release decisions, the practical test is simple: if the scan result changes the security posture of the runtime environment, it belongs in the go or no-go decision. If the artefact cannot be scanned reliably, that is itself a control gap worth fixing before the pipeline is trusted for production releases.
Risk and Threat Considerations
Container images are a common place for hidden exposure because they concentrate inherited code, runtime dependencies, and build artefacts in a form that is easy to distribute at scale. That creates a single failure point: one missed secret, vulnerable package, or misconfiguration can be replicated into many deployments very quickly. Attackers also benefit when images are pulled from untrusted registries or reused across environments without inspection.
Failure mechanism: The build process can introduce or preserve vulnerable content that never appears in source code review, including secrets left in layers, outdated packages from the base image, or unsafe files copied into the final image.
Impact: An exposed artefact can enable compromise before deployment, accelerate lateral reuse of secrets, or turn a routine release into a repeatable intrusion path across environments.
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, SLSA and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Artefact scanning validates integrity and detects malicious or vulnerable release content. |
| CM-2 — Baseline Configuration | Container images and artefacts should match approved baselines, including base layers and packaged content. | |
| IA-5 — Authenticator Management | Image scanning often finds embedded secrets and credentials that must be rotated or revoked. | |
| Recommendation — Verify release artefacts for integrity and malicious modification before deployment. Establish and enforce approved image baselines for release builds. Rotate or revoke exposed credentials found in build artefacts. | ||
| SLSA | Supply-chain Levels for Software Artifacts | Build artefact scanning supports provenance and integrity checks in software supply chains. |
| Recommendation — Require provenance and integrity checks for shipped artefacts. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Scanning helps inventory what software and components are actually packaged into release artefacts. |
| Recommendation — Inventory packaged software and block unknown components from release. | ||
Practitioner Guidance
What to prioritise: Scan the artefact that will be deployed, not only the repository that produced it. If the pipeline builds multiple stages, inspect the final stage and any intermediate layers that may be copied forward into release.
What to verify: Confirm that the scanner checks for vulnerabilities, malware indicators, misconfigurations, and embedded secrets, and that the release gate is enforced on the exact digest or artefact version that will ship. If the scan only runs on developer workstations or only on source code, it is not giving you the assurance you need.
Practitioner takeaway: The security question is not whether the code looked clean, but whether the shipped artefact is clean enough to trust in production; that is why image and build-artefact scanning belongs at release time, not as an afterthought.
Related resources from NHI Mgmt Group
- Guide: Container Image Security Guide
- What happens when container images are scanned only at build time?
- Who is accountable for remediating shared-library vulnerabilities across build pipelines and container images?
- What breaks when vulnerability management cannot see both build artefacts and runtime images?
- How should teams secure GitLab CI pipelines that build and deploy container images automatically?