TL;DR: GitGuardian shows that Docker secret handling breaks down when credentials are hard-coded into Dockerfiles, environment variables, or image layers, because runtime controls do not protect secrets that persist in build artefacts or inherited base images. The gap is governed secret exposure, not containerisation itself, and image scanning plus build-time secret mounts become mandatory control points.
At a glance
What this is: This is a Docker secrets management guide that argues the real risk is secret persistence in build artefacts, layers, base images, and environment variables, not containers alone.
Why it matters: It matters because IAM and NHI teams need to govern where credentials live across build and runtime paths, or exposed image-layer secrets can become a supply chain breach path.
By the numbers:
- In 2021, GitGuardian estimated that 7% of Docker Hub images contained at least one secret.
👉 Read GitGuardian's guide to Docker secrets management and image-layer exposure
Context
Docker secret management is the practice of keeping passwords, API keys, and other credentials out of places where they can persist beyond intended access. In containerised environments, that means treating Dockerfiles, image layers, environment variables, and shared base images as governance boundaries, not just deployment details.
The article’s core point is that runtime secret delivery is only part of the control model. If a secret is baked into an image layer or inherited from a base image, containerisation does not remove the exposure; it only changes where the secret can be found and copied from.
For IAM and NHI programmes, this is a lifecycle problem as much as a deployment problem. Secrets have to be governed from creation through build, runtime use, rotation, scanning, and revocation, or image distribution becomes an untracked credential channel.
Key questions
Q: What breaks when Docker secrets are copied into image layers or environment files?
A: Secrets can persist long after a container is deleted because they may remain in image layers, registries, or build history. That means API keys, passwords, and private keys can be recovered by anyone with access to the image. The practical failure is exposure of sensitive credentials across environments, not just inside a running container.
Q: Why do environment variables create more exposure than file-based secret mounts?
A: Environment variables are easier for applications to consume, but they are also easier for other tools to observe through process inspection, debugging, and logging. File-based mounts narrow that exposure because the secret stays in a controlled path rather than a broadly inspectable process context. For sensitive credentials, the difference is exposure surface, not convenience.
Q: How should teams prioritise build-time secret controls versus runtime secret controls?
A: Build-time controls should come first when the article’s risk is image-layer persistence, because a runtime-only control cannot remove a secret already embedded in a layer. Runtime controls still matter for access scope, but they do not fix a compromised artefact. Teams should therefore treat build-time secret handling as the earlier and more critical control boundary.
Q: How do organisations know whether their Docker secret controls are actually working?
A: They should verify that no credentials appear in Dockerfile instructions, image layers, build logs, or exported artifacts. Automated scanning should flag unsafe ENV or ARG usage, copied secret files, and layer residue before release. A working control leaves no recoverable secret material in the build pipeline or image supply chain.
Technical breakdown
Why Docker image layers retain secrets after builds
Docker images are layered filesystem artefacts, so any secret written during a build step can remain recoverable even if later steps delete the file. That matters because build-time commands, cached layers, and inherited base images can all carry credentials forward into registries and downstream deployments. BuildKit reduces this by mounting secrets only for the duration of a build step, rather than embedding them in the resulting layer. The key distinction is persistence: if a credential survives into an image layer, it is no longer scoped to the container runtime that created it.
Practical implication: Use build-time secret mounts and image-layer scanning to prevent credentials from surviving into distributed artefacts.
Why environment variables are a weak secret boundary in containers
Environment variables are convenient for application configuration, but they are a poor place for sensitive credentials because they can surface in process inspection, debugging output, orchestration metadata, and logs. That makes them useful for low-sensitivity configuration and risky for passwords, tokens, and certificates. File-based mounts and external secret stores reduce this exposure by separating the secret from the process environment. The architectural issue is not whether the container can read the value, but whether the value is broadly observable by adjacent tooling and operators.
Practical implication: Prefer file-mounted secrets or external secret managers when the credential has meaningful blast radius.
Why scanning images is part of secrets governance
Image scanning closes the gap left by build-time controls because base images, cached layers, and third-party packages can introduce secrets that were never present in the current repository. GitGuardian’s point is that secret hygiene cannot stop at source code scanning when the deployable artefact itself may already contain credentials. For container programmes, this is a supply chain issue as much as a secrets issue, because images are often promoted unchanged across environments. If the image is the unit of deployment, it also has to be the unit of inspection.
Practical implication: Add secret detection to CI/CD image pipelines and inspect both your own layers and inherited base images.
Breaches seen in the wild
- Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.
- PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Image-layer persistence is the governance failure Docker secrets expose: a secret that lands in a build layer outlives the runtime step that created it. That means the credential is no longer controlled by container isolation alone, because anyone who can pull the image can potentially recover it. The implication is that build artefacts must be governed as credential-bearing assets, not just software deliverables.
Runtime secret delivery does not solve build-time credential exposure: the common Docker security assumption is that secrets are safe if they are not present at runtime. That assumption fails when a build step, base image, or layer history already contains the secret before runtime begins. Practitioners have to treat image creation as a separate identity control point, not a downstream implementation detail.
Secret scanning has shifted from hygiene to control validation: once container images are the deployment primitive, scanning them is how teams verify that credential controls actually held across build, inheritance, and promotion. This is where OWASP-NHI concerns overlap with supply chain governance, because exposed machine credentials inside images are both an NHI problem and an artefact integrity problem. The practical conclusion is that image inspection belongs in the same governance path as rotation and revocation.
Docker secrets management now sits at the boundary of NHI and supply chain risk: passwords, API keys, and certificates used by containers are non-human identities in operational form, even when they look like simple configuration values. Their exposure in registries or shared layers creates a credential reuse problem that crosses teams and environments. Practitioners should therefore manage container credentials as governed NHI assets with build, runtime, and distribution controls.
Build-time secret handling is a named control gap, not a Docker-only issue: the specific failure mode is credential persistence in layers, images, and inherited artefacts. That is the point where conventional secret handling assumptions stop being reliable, because the secret escapes the context in which it was supposed to exist. The implication is that image provenance and secret lifecycle need to be assessed together.
From our research library:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to the State of Secrets Sprawl 2026.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Image-layer persistence is the real secret-management problem: if a credential survives into a Docker layer, container isolation no longer protects it, because the artefact itself becomes the secret-bearing object. That changes the governance target from runtime access alone to build provenance, base-image trust, and inspection before promotion.
Docker secrets should be treated as governed NHI assets, not just configuration values. Ownership, rotation, and revocation have to follow the credential through build, registry, and runtime paths, or image distribution becomes an uncontrolled reuse channel.
Secret scanning is the enforcement layer that tells you whether the policy actually held. According to the State of Secrets Sprawl 2026, 64% of valid secrets leaked in 2022 are still valid and exploitable today, which makes detection without revocation an incomplete control.
For practitioners
- Harden build-time secret handling Use BuildKit secret mounts or equivalent mechanisms so credentials are available only during the build step and are not written into image layers.
- Eliminate plaintext secrets from Dockerfiles Review Dockerfiles, Compose files, and build scripts for hard-coded passwords, API keys, and tokens, then replace them with file-based or external secret injection.
- Treat environment variables as low-trust configuration Reserve environment variables for non-sensitive settings and move sensitive values to mounted secret files or external secret stores with restricted access.
- Scan every deployable image for embedded secrets Add secret detection to CI/CD and check both first-party layers and inherited base images before images are promoted to registries or runtime clusters.
- Govern container credentials as NHI assets Track container-used passwords, API keys, and certificates through inventory, ownership, rotation, and revocation so image distribution does not outlive credential control.
Key takeaways
- Docker secrets exposure is less about containers themselves than about where credentials persist across build layers, runtime settings, and inherited images.
- The article’s evidence points to a long-tail exposure problem, not a one-time leak, because image artefacts can preserve secrets far beyond the original build.
- Teams that want containerised workloads to remain governable need build-time secret handling, image scanning, and credential lifecycle controls working together.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Docker images and layers can preserve secrets that should never reach distributed artefacts. |
| NHI-07 — Long-Lived Secrets | The article shows why secrets that persist in artefacts remain exploitable after initial exposure. | |
| Recommendation — Scan images for exposed secrets and remove any credential that appears in layers, logs, or inherited base images. Reduce credential lifetime by preventing secrets from persisting beyond the build step. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential handling in containers depends on lifecycle governance for authenticators and secrets. |
| Recommendation — Apply authenticator management controls to rotate and revoke container credentials on a defined lifecycle. | ||
| CIS Controls v8 | CIS-5 — Account Management | Container-used accounts and tokens need inventory, ownership, and revocation just like other credentials. |
| Recommendation — Maintain an inventory of container accounts and revoke stale credentials promptly. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Exposed image-layer secrets directly support credential access by attackers. |
| Recommendation — Map exposed container secrets to TA0006 and prioritise detection of images carrying credentials. | ||
Key terms
- Docker Secret: A Docker Secret is a managed credential stored and delivered to a container without placing the value in the image or plaintext configuration. In practice, it reduces casual exposure during deployment, but it still requires strict access scoping, revocation, and pipeline hygiene to be effective.
- Image Layer Persistence: Image layer persistence is the tendency for data written during a container build to remain recoverable in earlier layers even after later commands delete it. For secrets governance, that means a credential can survive the build process and become part of a reusable artefact that is easy to copy and hard to fully erase.
- BuildKit secret mount: A BuildKit secret mount is a build-time mechanism that exposes a credential only to the specific step that needs it. It helps prevent secrets from being written into image layers, but it does not replace governance over who can build, inspect, or publish the resulting artefact.
- Secrets Scanning: Automated tooling that scans source code repositories, CI/CD pipelines, and cloud environments to detect exposed secrets such as API keys, tokens, and passwords before they are exploited.
What's in the full article
GitGuardian's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step Docker Secrets and Swarm examples for mounting secrets as files inside containers
- Compose and sidecar patterns for standalone deployments that need secret injection without hard-coding values
- BuildKit secret mount syntax for preventing credentials from being written into image layers
- Practical image-scanning examples for detecting secrets inherited from base images and build artefacts
👉 GitGuardian's full post covers Docker Secrets, BuildKit, SOPS, and image scanning examples
Deepen your knowledge
NHI governance, secrets management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 31, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org