Notifications
Clear all
Topic starter
30/07/2026 11:22 pm
TL;DR: Docker secrets handling varies sharply across build, local, and production environments, and the article shows why image layers, environment variables, and ad hoc files each create different exposure paths, according to Infisical. The underlying lesson is that container secrecy fails when teams treat runtime credentials like static configuration.
NHIMG editorial — based on content published by Infisical: How to Manage Secrets in Docker
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams manage secrets in Docker images?
A: Teams should keep secrets out of image layers entirely, use build-time secret mounts for any authentication needed during builds, and prefer file-based secret delivery at runtime.
Q: Why do environment variables create risk in containerised runtimes?
A: Environment variables are easy to pass, but they are visible to inspection commands, inherited by child processes, and sometimes exposed in logs.
Q: When should teams prefer Docker Compose secrets over .env files?
A: Prefer Compose secrets when a container needs runtime credentials but the team wants to avoid plaintext files on disk.
Practitioner guidance
- Use BuildKit secret mounts for image builds Pass private registry tokens through BuildKit mounts so the credential is available only during the build step and never persists in image layers or history.
- Replace plaintext environment variables with file-mounted secrets For runtime containers, inject database passwords and API keys as mounted files instead of -e flags, because host tools and logs can expose environment variables.
- Centralize secret sourcing before Docker execution Use a single secret manager as the source of truth for build, Compose, and Swarm workflows so the same credential is not copied into .env files or repository secrets.
What's in the full article
Infisical's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step Dockerfile and Compose examples for handling build-time and runtime secrets
- Practical CLI commands for injecting secrets into local development and GitHub Actions workflows
- A full Swarm deployment pattern showing how cluster-managed secrets differ from single-host handling
- Implementation notes for mapping one secret strategy across development, test, and production
👉 Read Infisical's guide to managing secrets across Docker build, Compose, and Swarm →
Docker secrets in practice: are your runtime controls keeping up?
Explore further
30/07/2026 11:24 pm
Secret exposure in Docker is a lifecycle failure, not just a build mistake. The same credential can be exposed at build time, runtime, or cluster distribution time, and each stage requires different handling. The article shows that teams often solve one stage while leaving the others exposed, which is why isolated point controls do not solve container secrecy. Practitioners should treat Docker secrets as a lifecycle governed asset, not a deployment convenience.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
A question worth separating out:
Q: What should organisations do before moving container secrets into production?
A: Map each secret to its lifecycle stage, then decide whether build-time, runtime, or cluster-distributed handling is required. That prevents teams from reusing the same exposure pattern everywhere, which is how container secret sprawl usually starts.
👉 Read our full editorial: Managing Docker secrets without image leaks or runtime exposure
