Should organisations scan Docker images for secrets if they already secure the source code?

Yes. Source-code controls do not cover inherited layers, copied files, or secrets that entered through a parent image. Image scanning verifies what actually ships, not just what the repository contains. In practice, it is one of the few controls that can surface credential residue after the build has completed.

Why This Matters for Security Teams

Securing source code is necessary, but it is not sufficient once a Docker image becomes the thing that actually runs. Secrets can arrive through base layers, copied build artefacts, environment variables, or package install steps, even when the repository itself looks clean. That is why container image review belongs in the release path, not as an optional clean-up task. The issue is broader than code hygiene and sits squarely in supply chain risk and NHI governance.

The practical failure mode is simple: a developer removes a key from the repo, but the build still inherits a token from a parent image or leaves credentials in a layer history. GitGuardian’s Guide to the Secret Sprawl Challenge highlights the scale of the problem, including around 100,000 valid secrets found in public Docker images, with ENV instructions accounting for 65% of container leaks. OWASP also treats secrets in build and runtime paths as a first-class identity risk in the OWASP Non-Human Identity Top 10.

In practice, many security teams encounter the container leak only after the image has been promoted and the credential has already been reused outside the build pipeline.

How It Works in Practice

Image scanning should look for secrets in both the filesystem and the image metadata, not just for known vulnerable packages. That means checking layer contents, exported ENV values, shell history left by build steps, copied config files, and embedded keys in application bundles. Source control scanning still matters, but image scanning answers a different question: what secret material is actually present in the artifact that will be deployed.

A workable process usually combines pre-build and post-build controls:

• Scan the source repository to catch committed credentials early.
• Scan the built image before publishing it to a registry.
• Block promotion if secrets appear in layers, metadata, or copied files.
• Prefer ephemeral credentials and short TTLs so any residue has limited value.
• Revoke exposed secrets automatically, because detection alone is not enough.

This matters because secrets can enter through inherited components. A base image may already contain stale credentials, or a package install script may write tokens during build time. The Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful here: static credentials create long-lived blast radius, while dynamic secrets reduce persistence when they are properly issued and revoked. For broader supply-chain context, the CI/CD pipeline exploitation case study shows why build systems themselves are part of the trust boundary, not just the application code.

Best practice is to treat image scanning as a release gate, then pair it with registry policy, signed images, and runtime secret delivery from a dedicated secret manager rather than hardcoding values into the container. This guidance tends to break down in multi-stage builds that copy opaque vendor artefacts into final images, because scanners may miss secrets hidden inside compressed blobs or binaries.

Common Variations and Edge Cases

Tighter image controls often increase build friction, so organisations have to balance release speed against the cost of secret exposure. That tradeoff becomes more visible in legacy pipelines, especially where developers rely on inherited base images, shared runners, or vendor-supplied packages that are difficult to inspect.

There is no universal standard for this yet, but current guidance suggests three common edge cases deserve special attention. First, private registries are not automatically safer than public ones: a hidden image can still carry leaked credentials. Second, a clean application image can still be risky if the parent layer includes secrets or if build-time tooling caches tokens. Third, scanning alone does not solve the problem when secrets are valid and reusable after discovery, which is why revocation and rotation must follow detection.

NHIMG’s Reviewdog GitHub Action supply chain attack is a reminder that tooling can leak credentials outside the application boundary, and the Shai Hulud npm malware campaign shows how quickly secrets can be harvested once they are reachable in automated workflows. The right response is not to assume source control is enough, but to enforce inspection at the image, registry, and runtime layers as one control chain. In mature environments, image scanning becomes most valuable when it is coupled to automated secret rotation and a strict policy against long-lived credentials.

Related resources from NHI Mgmt Group

• How should security teams manage secrets in Docker images?
• When should organisations replace static secrets with ephemeral access for agents?
• Should organisations keep classic PAM if they are moving to dynamic access controls?
• Should organisations replace static secrets before adopting more agentic workflows?