How should security teams handle secrets that may be embedded in container images?

Why This Matters for Security Teams

Embedded secrets in container images are not just a hygiene issue; they are a workload identity exposure that can turn a build artifact into a reusable access path. If a token, certificate, or API key is baked into an image layer, every pull, registry copy, and derivative image can extend the blast radius. That makes remediation a rotation problem, a provenance problem, and a prevention problem at the same time.

Current guidance suggests treating the image as an untrusted carrier of credentials until proven otherwise. The practical risk is amplified by the persistence of valid leaked secrets in the wild: NHIMG research on The State of Secrets Sprawl 2026 found that 64% of valid secrets leaked in 2022 are still valid and exploitable today, which is a strong reminder that deletion from source does not equal revocation. This is also why the OWASP Non-Human Identity Top 10 remains relevant here: a container image can silently carry NHI access that outlives the image’s intended use.

In practice, many security teams encounter the problem only after the image has already been promoted through CI/CD and replicated into multiple environments, rather than through intentional credential design.

How It Works in Practice

The response sequence should start with discovery, but not stop there. Security teams need to inspect build history, Dockerfile instructions, layer metadata, and pipeline logs to locate where the secret entered the image. That includes hardcoded ENV values, copied files, build arguments, and generated artifacts that accidentally captured credentials during image assembly. Once the secret is identified, revoke or rotate it first, then remove the source material and rebuild from a clean baseline.

A useful operating model is to separate detection from enforcement. Detection identifies where the secret exists; enforcement stops the same failure from recurring. Preventive controls should include pre-build checks on Dockerfiles, argument validation, secret redaction in logs, and layer scanning before registry push. NHIMG’s Guide to the Secret Sprawl Challenge is a useful reminder that secrets rarely stay confined to a single repo or stage once automation starts copying them across systems. For container-centric pipelines, this aligns with the OWASP guidance on protecting identity material as part of software supply chain control, not just endpoint scanning.

• Revoke the credential before rebuilding, so the old image cannot keep working.
• Search image layers, build cache, and CI logs, not just the final filesystem.
• Use short-lived credentials for build-time access where possible, so exposure window is narrower.
• Block builds that introduce secrets through Dockerfile instructions, environment variables, or copied files.
• Record image provenance so downstream teams know which artifacts may have carried exposed credentials.

Teams that already manage registry controls should still validate whether derived images inherit the same secret-bearing layers, because the exposure can persist long after the original developer commit is gone. This guidance tends to break down in highly automated release pipelines that reuse cached layers across many environments because the same embedded secret can be replicated faster than it can be found.

Common Variations and Edge Cases

Tighter secret controls often increase build friction, so organisations have to balance release speed against the cost of credential sprawl. That tradeoff becomes sharper when container images are produced by multiple teams, third-party builders, or ephemeral CI runners that are difficult to standardise.

There is no universal standard for every environment, but current guidance suggests a few practical distinctions. If a secret is used only during build, prefer a JIT secret issued for the pipeline job and revoked immediately after completion. If a secret must exist at runtime, keep it outside the image and inject it through a controlled runtime mechanism rather than baking it into a layer. If an image has already been distributed broadly, assume downstream copies are still live until registry cleanup and revocation are complete. NHIMG’s Reviewdog GitHub Action supply chain attack and Shai Hulud npm malware campaign both illustrate how quickly automation can spread exposed credentials once the pipeline itself becomes part of the attack path.

For teams using policy-driven release gates, pair image scanning with a hard decision point that prevents promotion when embedded secrets are found. This aligns with the operational intent behind the OWASP Non-Human Identity Top 10, but it still requires human ownership for rotation and cleanup. The main edge case is legacy workloads that depend on long-lived static credentials; those environments usually need a phased migration, not a single cutover, because replacing the image without replacing the credential only shifts the exposure.

Related resources from NHI Mgmt Group

• 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 handle leaked secrets across developer workflows?
• How should security teams handle exposed secrets in modern software pipelines?