What breaks when developers put secrets in Docker Compose files or environment variables?

Why This Matters for Security Teams

Secrets in Docker Compose files or environment variables are not just a developer convenience problem. They create a governance failure that turns ephemeral build-time values into durable, copyable credentials. Once a secret is embedded in a compose file, a .env file, or pipeline configuration, it can move through version control, ticketing systems, chat tools, and backup stores far beyond the original container boundary. That weakens revocation, complicates auditability, and undermines the assumption that local configuration stays local.

This is especially dangerous when the secret authorises access to cloud APIs, databases, signing services, or automation accounts. In those cases, the exposed item is effectively a non-human identity credential, and the control problem becomes closer to NHI governance than ordinary developer hygiene. The OWASP Non-Human Identity Top 10 is useful here because it frames the issue as lifecycle, exposure, and privilege management rather than only storage location. In practice, many security teams encounter this only after a credential has already been reused in another environment and the original source file has been copied into places nobody remembered to check.

How It Works in Practice

Docker Compose encourages readable configuration, but readable is not the same as safe. Anything stored in a compose file, an .env file, or a shell-exported variable can be surfaced by simple inspection, inherited by child processes, or captured by tooling that records build and runtime state. Even if the file is not committed to Git, it may still appear in CI logs, deployment manifests, debugging output, or container metadata.

The control gap is that environment variables are a transport mechanism, not a secret management system. They do not provide encryption, rotation, access approvals, or strong audit trails. They also tend to persist longer than intended when developers copy a local setup into shared staging or test systems. Current guidance suggests using secret managers, runtime injection, and short-lived credentials instead of embedding values directly in Compose definitions. That aligns with the intent of NIST SP 800-53 Rev 5 Security and Privacy Controls, especially controls around least privilege, configuration management, and media protection.

• Keep secrets out of source-controlled compose files and .env files.
• Inject credentials at runtime from a managed secret store or orchestration platform.
• Use unique, scoped credentials per environment so one leak does not expose everything.
• Restrict who can read container definitions, logs, and process metadata.
• Rotate exposed credentials quickly and invalidate any reused copies.

This guidance tends to break down in legacy CI/CD environments where build steps print environment values, because the secret is already visible before container startup controls can help.

Common Variations and Edge Cases

Tighter secret handling often increases deployment complexity, requiring organisations to balance operational speed against exposure reduction. That tradeoff is especially visible in small teams that rely on Compose for local development and simple staging promotion. In those settings, there is no universal standard for how much secret material can safely live in developer workflows, but best practice is evolving toward secretless local config plus managed injection at runtime.

There are also edge cases where the immediate risk looks lower but is still material. A harmless-looking API token may later gain broader permissions, and a database password intended for a disposable test system may be copied into a production-adjacent environment. Another common mistake is assuming that “not in Git” means “not exposed,” when the same value still exists in shell history, CI variables, crash dumps, container inspection output, or shared clipboard tooling. That is why NHI governance matters even when the asset is called a password or token rather than a formal service account. Security teams should treat any credential used by software as an identity with lifecycle, ownership, and revocation requirements, not as a convenience string.

For organisations handling regulated workloads, the risk extends into access control and auditability expectations shaped by frameworks such as the NIST security control catalog. The practical test is simple: if a secret can be copied into a chat, pasted into a ticket, or left in a compose file without immediate detection, then it is already too easy to misuse.

Related resources from NHI Mgmt Group

• What breaks when AWS credentials are stored in environment variables or config files?
• What breaks when developers keep secrets in .env files and chat logs?
• What breaks when CI/CD secrets live in shared environment variables?
• What breaks when secrets are written into agent environment files?