Secrets in container images are credentials or keys accidentally baked into an image during build or packaging. They persist across copies and deployments, creating exposure if the image is shared, stored, or inspected. In NHI terms, this includes API keys, tokens, certificates, and passwords that should be injected at runtime instead.
Why secrets become dangerous once they are baked into an image
Container images are meant to be copied, cached and reused, which makes embedded secrets unusually sticky. If a credential is built into a layer, every downstream copy of that image can inherit the exposure, even when the application itself is redeployed cleanly.
The problem is not limited to running containers. Images are often stored in registries, mirrored across environments, shared with partners, scanned by tools and inspected by incident responders, so a leaked secret can surface long after the original build pipeline has moved on. That persistence turns a simple build mistake into a broad trust and access problem.
What kinds of secrets show up in images
The most common examples are API keys, bearer tokens, passwords, private keys, certificates and cloud credentials that were copied into a Dockerfile, passed through build arguments, left in environment variables during image creation, or added by scripts and packaging steps. Anything that can authenticate to a service or unlock data should be treated as high-value if it lands in an image.
These secrets are especially problematic when they are reusable across systems or environments. A single baked-in token may open source control, a registry, a database or an internal API, which means the impact of exposure depends on both the secret’s scope and how widely the image is distributed.
How organisations should think about exposure and prevention
Exposure review starts with the image supply chain itself: identify where images are built, stored, promoted and deployed, then inspect those paths for build-time secret handling. The practical test is simple, if a secret should only exist at runtime, it should not be present in the artifact that gets copied everywhere.
Prevention depends on runtime injection, secret managers, build pipeline hygiene and image hygiene. Keep secrets out of Dockerfiles and layers, use ephemeral or centrally managed injection where possible, and prefer the Container Image Security Guide for the wider image hardening context, including scanning, signing and registry controls.
Detection, cleanup and post-exposure response
Detection works best when it combines image inspection with secret-scanning in source, build logs and registries. Once a secret has appeared in an image, assume it may have been copied beyond the original environment and review where that image was pushed, cached or pulled.
Cleanup is not just image deletion. The exposed credential should be rotated or revoked, dependent services should be checked for misuse, and any associated access paths should be reviewed for persistence. The Guide to the Secret Sprawl Challenge is useful here because it frames remediation as both a detection and lifecycle problem, not just a one-time leak.
Risk and Threat Considerations
Secrets in images create durable exposure because images are portable, cacheable and often replicated outside the team that built them. That makes them attractive to attackers who can pull an image, inspect its layers or harvest credentials from public registries, backup systems or CI/CD artifacts.
Failure mechanism: A secret is embedded during build or packaging, then survives in one or more image layers and remains recoverable after the application is redeployed or the original source is cleaned up.
Impact: Attackers can reuse the credential for unauthorized access, lateral movement or data extraction, and defenders may need to treat every copy of the image as a potential compromise point.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Secrets in images expose reusable access material that must be controlled and removed. |
| CIS-16 — Application Software Security | Build pipelines and artifact handling are part of secure software delivery for container images. | |
| Recommendation — Inventory exposed credentials and revoke or rotate them immediately after image leakage. Scan builds and artifacts for secrets before publishing container images. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Embedded secrets are authenticators or key material whose lifecycle must be managed. |
| SC-28 — Protection of Information at Rest | Image layers can store sensitive secret material at rest in build artifacts and registries. | |
| SA-10 — Developer Configuration Management | Secret-free build and packaging practices depend on controlled configuration of artifacts. | |
| Recommendation — Remove baked-in authenticators and enforce rotation and revocation for exposed secrets. Prevent sensitive material from persisting in stored image layers and registry artifacts. Keep build outputs free of secrets through controlled packaging and release processes. | ||
Practitioner Guidance
Why practitioners should care: The right control decision is to separate build artifacts from runtime credentials, because image immutability works against you once a secret has been embedded. A leaked image can outlive the release that created it, so response has to include both rotation and artifact containment.
Practitioner takeaway: If a secret is ever visible in an image, assume it is already beyond the build system and handle it as a credential incident, not a cosmetic cleanup task.
Related resources from NHI Mgmt Group
- How should security teams handle secrets that may be embedded in container images?
- Who is accountable when exposed container images contain secrets and credentials?
- What breaks when container images are not checked for embedded secrets and risky configuration?
- Why do secrets embedded in container images create supply chain risk?