Where do container security controls fail when teams scan only source code?

Where source-only scanning breaks container security

Source-only scanning misses the build-time shift in trust. A repository scan can tell you what was committed, but it cannot tell you what the build system added, what the base image already contained, or how runtime configuration changed before the image was published. That gap matters because the deployable artefact is what attackers actually encounter, and it is often the first place vulnerable dependencies, leaked secrets, or unsafe defaults become real exposure.

For containerised software, the security boundary is not the repository alone. A Dockerfile, base image, package manager, build pipeline, and post-build configuration all influence the final image. If teams stop at source code, they may review an apparently clean commit while the produced artefact still carries inherited libraries, copied credentials, or misconfigured settings that never existed in the repo itself. The correct unit of analysis is the image that will run, not just the code review queue.

That is why NIST SP 800-190 Container Security treats image, registry, orchestrator, and runtime risk as separate concerns. It reflects the practical reality that build and deployment stages can introduce weaknesses after source scanning has finished. Teams need artefact-aware controls, such as image inspection, base-image governance, and registry hygiene, because the final container can differ materially from the repository that produced it.

Build pipelines also change what should be trusted. Dependencies may be pulled from external registries, layers may embed stale or inherited content, and configuration may be injected by CI/CD variables, Helm charts, or orchestration defaults. Those changes can create hidden attack surface even when source review is strong. A clean source tree does not guarantee a clean image, especially when the pipeline assembles software from multiple upstream components.

What gets introduced after the repo scan

The most common blind spots are dependency drift, image layering, and configuration drift. A source scan can confirm that no secret appears in the codebase, yet the build may still copy a secret file into a layer, install a vulnerable package from an upstream base image, or enable a service endpoint through container defaults. In practice, the final image often contains both inherited risk and build-time risk.

That distinction is important because many container compromises come from what was not visible in the repository. The repository may not show the full package set, the exact OS packages in the base image, or the environment values that turn a safe component into an exposed one. The artefact can therefore be materially different from the code review target, even when the source files themselves are unchanged.

NHIMG’s Massive Docker Hub Secrets Leak is a useful example of why the final image matters: secrets can persist inside container images long after the source repository looks clean. The same principle applies to Secrets in Docker Hub images, where leaked material was embedded in image content rather than the commit history alone. Those cases show why image-layer review belongs alongside source scanning, not after it.

Teams should also watch for configuration injected outside the repo, because orchestration and deployment files can change exposed ports, privilege settings, network reachability, and secret mounting. If those controls are not examined with the built artefact, the team may misunderstand the actual runtime posture.

What practitioners should verify before they trust the image

Source scanning remains useful, but only as one input to a larger artefact review. Practitioners should verify the image digest they will deploy, the exact base image it inherits, the package inventory inside the container, and any secrets or credentials introduced by build steps or deployment manifests. If those elements are not pinned and reproducible, the security team is reviewing intent rather than execution.

That also means checking where the image came from and whether the build is deterministic. A container image that cannot be traced to a known build recipe is harder to assess, harder to reproduce, and harder to compare against policy. For teams operating at scale, the practical question is whether the build process leaves enough evidence to prove what entered the image and why.

For a broader control view, CIS Controls v8 supports inventory, vulnerability management, and secure configuration work that container programmes rely on, while CSA Cloud Controls Matrix is useful where container security sits inside cloud governance, IAM, and infrastructure controls. If the review focuses on the image and registry as an artefact chain, those frameworks help turn a source-only habit into a full lifecycle control set.

Risk and Threat Considerations

Source-only scanning creates a false sense of completeness. Attackers do not care whether a vulnerable package or secret was present in Git, they care whether it landed in the shipped image, registry, or running container. The failure mode is simple: the build process becomes the point where hidden dependencies, copied secrets, or unsafe defaults are introduced after review.

Failure mechanism: Teams inspect committed code, but the pipeline assembles a different runtime artefact by adding base-image content, fetched dependencies, or deployment-time configuration that was never scanned.

Impact: Vulnerabilities, credentials, or unsafe settings survive into the deployed container, which can expose the workload, widen blast radius, and force emergency rotation or rebuild after release.

Practitioner Guidance

What to prioritise: Treat the image and its provenance as the security object, then layer source review underneath it. If source and image do not match one-to-one in a reproducible build, the artefact controls need to be tightened before release.

What to verify: Confirm the exact image digest, base-image lineage, dependency set, and any build-time or deployment-time secrets before you trust a container for production. If the only evidence is a clean repository scan, the review is incomplete.

Common mistake: Assuming that a clean repo means a clean container. The practical error is reviewing code while ignoring the pipeline, because the pipeline is where the deployable risk often appears.

Practitioner takeaway: Container security starts where source control ends, so the control question is not “was the code scanned?” but “was the final artefact that will run actually inspected and governed?”

Related resources from NHI Mgmt Group

• Why do security controls for insecure code patterns fail when teams rely on function names alone?
• How should security teams decide whether JIT access is safe for non-human identities?
• How should security teams protect source code repositories from identity abuse?
• How can security teams tell whether their container controls are really working?