They miss the actual security state of what will run. A clean repository can still produce a vulnerable image through build-time dependencies, outdated base layers, or malicious packages. The result is false confidence, because the repository no longer matches the deployable artefact and production risk is discovered too late.
Why This Matters for Security Teams
Scanning source code alone gives teams an incomplete view of exposure because the deployable container is assembled later, often from base images, package registries, build scripts, and transient dependencies that never appear in the repository. Security leaders usually assume the repo scan is enough because it is earlier in the workflow, but the risk that matters is the one in the artefact actually pushed to the registry and orchestrator. That gap becomes especially dangerous when the build pipeline pulls in unpinned packages, cached layers, or image parents with known weaknesses.
For practitioners, this is not a theoretical mismatch. It is a control failure between software supply chain review and runtime reality. NIST Cybersecurity Framework 2.0 treats risk management as an end-to-end process, and container security needs the same discipline. If the security team cannot explain what was added during build, what inherited risk came from the base image, and what changed before deployment, the scan result is only partially meaningful. In practice, many security teams encounter this only after a vulnerable image has already been promoted into production, rather than through intentional build-stage control.
How It Works in Practice
Container security works best when repository scanning, build-time inspection, and image scanning are treated as complementary controls rather than substitutes. Source scanning can catch insecure code patterns, but the built image is where the real attack surface is assembled. That includes the operating system layer, language runtime, installed packages, copied secrets, build tools that accidentally remain in the final layer, and any changes introduced by the CI pipeline.
Teams should scan the image after build, before promotion, and again after base image refreshes. The key question is not only whether the application code is vulnerable, but whether the resulting artefact contains exploitable packages, exposed credentials, or outdated OS components. This lines up well with the supply chain and vulnerability management practices described in CISA secure software development guidance and the software assurance expectations in NIST software supply chain security practices.
- Scan the repository to catch insecure code, dependency declarations, and obvious secrets before build.
- Scan the built image to identify inherited OS packages, vulnerable libraries, and build artefacts that will actually ship.
- Compare the SBOM or package inventory against approved baselines so drift is visible.
- Block promotion when the image contains critical findings, not just when source code looks clean.
- Re-scan on each rebuild because the same source can produce a different image when dependencies or base layers change.
For organisations using signed artefacts and admission controls, image scanning becomes even more important because deployment trust is tied to the artefact, not the repository. Where CI pipelines are highly dynamic, ephemeral, or build from multiple stages, source-only scanning tends to break down because the final image is assembled outside the repository boundary and the security team loses visibility into what was added or retained.
Common Variations and Edge Cases
Tighter build-stage control often increases pipeline overhead, requiring organisations to balance release speed against the need for artefact fidelity. That tradeoff is real, especially for teams with frequent releases, multi-stage builds, or separate platform engineering and application security ownership.
There is no universal standard for whether source, image, or both should be the primary gate in every environment. Best practice is evolving toward layered verification, with image scanning treated as mandatory for anything that will be deployed. This is especially important when base images are shared across many services, when packages are installed at build time from public registries, or when a benign source tree still produces a risky container because of hidden build context. The same applies when developers scan a local image that differs from the CI-built artefact. MITRE ATT&CK is useful here because many container compromises start with external dependency abuse, credential exposure, or software that was trusted too early in the pipeline.
For regulated environments, the question becomes one of evidence as much as prevention. Teams often need to show that the scanned artefact is the same one promoted through change control, and that the scan occurred after the final layer was created. These controls are weakest in monorepos, build farms that reuse cached layers aggressively, and teams that copy binaries into images without preserving provenance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP-1 | Build and deployment controls must reflect the actual container artefact, not only source code. |
| MITRE ATT&CK | T1195 | Supply chain compromise can enter through dependencies and build inputs, not just code. |
| CIS Controls | 4.4 | Vulnerability detection needs inventory visibility across deployed artefacts, including containers. |
Verify the final image before promotion so process controls cover what will actually run.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
