How should security teams manage secrets in Docker images?

Why This Matters for Security Teams

Docker images are often treated as immutable artifacts, which makes secrets especially dangerous when they are written into layers, environment variables, or build logs. Once embedded, those credentials can be extracted from a registry, a cached layer, or a compromised host long after the original build is forgotten. The practical risk is not just leakage at rest. It is also reuse across pipelines, clusters, and downstream deployments. NHIMG research on the Guide to the Secret Sprawl Challenge shows why sprawl persists when secrets are copied into too many places to track cleanly.

That concern is consistent with broader guidance from the NIST Cybersecurity Framework 2.0, which treats protect and detect as inseparable: if a secret can be recovered from an image, the exposure problem has already crossed into incident response territory. For container-specific identity hygiene, the OWASP Non-Human Identity Top 10 reinforces that machine credentials must be managed as active identities, not convenience values tucked into build artifacts. In practice, many security teams encounter image-borne secrets only after a registry scan or compromise has already revealed them.

How It Works in Practice

The clean pattern is to separate build-time authentication from runtime secret delivery. During builds, use secret mounts or equivalent ephemeral mechanisms so the build process can read a credential without baking it into the final layer. That keeps tokens out of Dockerfile instructions, shell history, and layer metadata. At runtime, deliver secrets through files or native secret stores rather than ENV variables, because environment variables are easier to leak through inspection tools, crash dumps, and process listings. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful here because the core question is not just where the secret lives, but how long it stays valid.

Operationally, teams should treat every Docker build as a control point:

• Use multi-stage builds so compilation and dependency access happen in one stage, while the final image remains free of credentials.
• Pass build-time secrets through ephemeral mounts instead of ARG or ENV instructions.
• Scan both the built image and the registry copy for hardcoded credentials before promotion.
• Revoke any exposed secret immediately, then rotate dependent credentials and review downstream access paths.

The reason this matters is simple: image scanning is a detection control, not a containment strategy. GitGuardian’s The State of Secrets Sprawl 2025 reported around 100,000 valid secrets in public Docker images, with ENV instructions alone accounting for 65% of container leaks. That is why container builds should be designed to avoid secret persistence rather than hoping scanners will catch every mistake. These controls tend to break down in legacy pipelines that reuse old Dockerfiles, because build arguments and cached layers preserve sensitive material across releases.

Common Variations and Edge Cases

Tighter secret handling often increases build complexity, requiring organisations to balance developer convenience against credential exposure risk. The biggest tradeoff is that some workflows are still built around long-lived credentials, shared base images, or CI systems that expect environment-based authentication. Current guidance suggests phasing those patterns out, but there is no universal standard for every toolchain yet. In those cases, the safest approach is to shorten credential lifetime, scope access narrowly, and make revocation automatic whenever the image, runner, or registry is suspected of exposure.

Edge cases usually appear in places teams do not classify as “application code.” A build script that pulls from a private package feed, an init container that exports a token to a temp file, or a debug layer left in a non-production image can all reintroduce the same problem. NHIMG’s Top 10 NHI Issues and the CI/CD pipeline exploitation case study are relevant because image secrecy failures often start in build orchestration, not in the application runtime itself. For teams with strict compliance needs, the practical rule is that if a secret is necessary to build the image, it should be treated as transient infrastructure access, not as part of the shipped artifact.

Related resources from NHI Mgmt Group

• How should security teams prevent hardcoded secrets from becoming a breach path?
• How should security teams decide whether JIT access is safe for non-human identities?
• How should teams reduce the risk from exposed NHI secrets?
• How should security teams implement zero standing privilege for service accounts and AI agents?