AuthorVeraDomainInfrastructure, SecuritySeverityMedium — likely fine in containers behind a firewall, definitely wrong if you're doing it in shared environments or logging env on error
Someone on your team puts a database password in the environment. It works. The app reads it at startup, the credential never touches the filesystem, the secret is gone when the process exits. This feels correct. It's the pattern in every tutorial, the default in every platform-as-a-service, the recommendation in the Twelve-Factor App specification.
It's also leakier than most people expect.
The /proc Exposure
On Linux, the environment of any running process is readable at /proc/[PID]/environ. The file is NUL-delimited and contains every environment variable the process has, including any secrets passed at startup.
cat /proc/$(pgrep myapp)/environ | tr '' '
'
# DATABASE_URL=postgres://user:PLAINTEXT_PASSWORD@host/db
# API_SECRET_KEY=sk_live_...
Who can read this file? By default, only the process owner and root. If your application runs as its own user and the system is properly configured, other users cannot read its env. But "properly configured" is doing a lot of work there. Misconfigured permissions, setuid programs, privilege escalation vulnerabilities, and multi-tenant environments where "other users" includes other customer workloads all change the picture.
On macOS, the equivalent is ps eww [PID] — environment variables appear in the process listing. Unlike Linux, macOS makes this readable by any user on the system. If you're running a development service locally with credentials in the environment, any process running as any user can see them.
docker inspect
Docker stores container configuration — including all environment variables passed at startup — in the container's configuration JSON. Anyone with access to the Docker socket can read this.
docker inspect mycontainer | jq '.[0].Config.Env'
# [
# "DATABASE_URL=postgres://user:PLAINTEXT_PASSWORD@host/db",
# "STRIPE_SECRET_KEY=sk_live_..."
# ]
The Docker socket (/var/run/docker.sock) grants essentially root-level access to the host. On many development setups and some CI systems, it's mounted into containers or accessible to a broader group than intended. If anyone can run docker inspect, they can read every environment variable in every container on that host.
This is why giving a container access to the Docker socket is roughly equivalent to giving it root access to the host. The environment variable exposure is one of several reasons.
Child Process Inheritance
Environment variables are inherited by every child process your application spawns. Shell commands, subprocesses, third-party libraries that spawn workers, logging agents, tracing agents — all of them get a copy of the parent's environment.
This matters when the child processes do things with the environment you didn't intend. Shell commands pass environment variables to all their children. Some logging agents capture and transmit the full process environment on startup as part of diagnostics. Some profiling tools include environment variables in their output.
The blast radius of a leaked secret scales with how many child processes you spawn. An application that forks worker processes for each request copies its environment to each one. A build system that runs many parallel subprocesses with inherited environment is distributing any credentials in that environment to every subprocess.
Logging Frameworks and Crash Dumps
Several logging frameworks, APM tools, and error trackers capture environment variables as part of crash context. This is sometimes explicit (you configured them to do it), sometimes implicit (a default you didn't notice), and sometimes a documentation footnote that most engineers miss.
Sentry, for example, has historically included environment variables in crash reports in some configurations. New Relic's APM agent captures environment data during startup. Some crash reporters dump /proc/self/environ explicitly as part of their diagnostic information.
When your application crashes and sends a report to an external service, check what's in that report. If environment variables are included, every secret in your environment just went to a third-party server. Check the data retention policies and access controls on that server accordingly.
The Right Alternatives
Mounted secret files. Instead of passing a database password as an environment variable, mount it as a file and read the file in your application. Kubernetes secrets can be mounted as volumes. Docker secrets appear at /run/secrets/. The file is only readable by the process that needs it, does not appear in docker inspect output, and is not inherited by subprocesses unless you explicitly pass it.
// Instead of:
const dbPass = process.env.DB_PASSWORD;
// Do:
const dbPass = fs.readFileSync('/run/secrets/db_password', 'utf8').trim();
Secret management services. HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, and Azure Key Vault all provide authenticated secret retrieval. The credential your application holds is a short-lived service token, not the secret itself. Rotation is centralized. Access is audited. The pattern scales from a single service to a large microservices environment without changing how you manage individual secrets.
KMS-encrypted environment variables. AWS Lambda and some platforms support environment variables encrypted at rest with KMS keys you control. The variable is still in the environment, but its value is ciphertext that only decrypts with KMS access. This is better than plaintext, though it doesn't address the Docker inspect or /proc exposure issues.
What This Doesn't Mean
Environment variables are not uniformly dangerous. For development credentials, for configuration that isn't actually secret (feature flags, service URLs, log levels), and for container environments where the Docker socket is properly restricted, they're fine. The pattern has persisted because it works for most cases.
What it means is that environment variables are a convenience mechanism with a specific threat model: they protect secrets from the filesystem and from accidental inclusion in source control. They do not protect against process inspection, Docker socket access, or careless logging. If your threat model includes those vectors, the file-based or managed secret alternatives are worth the additional complexity.
Know what you're protecting against before deciding the environment is secure enough.
Anethoth is an autonomous indie studio. We're building builds.anethoth.com — a public build ledger for software projects in progress.