Environment variables for secrets: the places they leak

Environment variables keep secrets out of source code, but they are readable by any process with the right access and they surface in logs and dumps. OWASP advises against them unless other methods are not possible, and recommends mounted files or in-memory injection instead.

Why teams use them

Environment variables solve a real problem. They keep credentials out of the repository, they change per deploy, and every language can read them. The twelve-factor method recommends them for exactly these reasons. For a low-risk value such as a feature switch, they are fine.

For credentials that unlock data, the picture is less friendly.

Where the leaks happen

The OWASP Secrets Management Cheat Sheet states that environment variables are readable by all processes and can appear in logs or system dumps. Those three phrases map to concrete habits.

• Child processes. A process you start usually inherits the whole environment. A build tool, a shell script or a plugin that you launch receives secrets it never needed.
• Diagnostics. A startup banner that prints the environment, an error page that lists settings, or a crash report can write every variable to a place people can read.
• Image and build metadata. Docker's own documentation says build arguments and environment variables persist in the final image, so anyone with the image can read them. Use build secret mounts instead.
• Process inspection. Anyone with enough access on the host can inspect a running process, and its environment comes with it.

What OWASP recommends instead

The same cheat sheet says to prefer mounted files or in-memory injection. Let the orchestrator mount secret files at runtime and never bake them into images. It also says never to hardcode secrets with Docker ENV or ARG. For stronger setups it suggests a sidecar that fetches secrets into a shared in-memory volume, and short-lived dynamic secrets where possible.

The cheat sheet's exact wording on environment variables is that they are not recommended unless the other methods are not possible. That is a reasonable default, not a ban.

A practical rule set

1. Use environment variables for non-sensitive settings.
2. For credentials, mount files with tight permissions or fetch at runtime from a secrets manager.
3. Never print the whole environment. Log specific, safe keys by name.
4. Do not let secrets pass into subprocesses that do not need them.
5. Keep secrets out of image layers by using build secret mounts.

See also files versus environment variables, a decision guide.

Where Safeguard fits

Safeguard policies and gates can stop a pull request that adds a hardcoded credential from merging, which covers the case where a variable gets replaced by a literal.

Quick check

Sources

• OWASP Secrets Management Cheat Sheet
• Docker documentation, Build secrets
• The Twelve-Factor App, III. Config

Last reviewed: 19 October 2026.