Dockerfile Security: Avoid Potential Secrets in ENV Keys

Secrets in ENV become part of image layers and can leak through registries and logs. Inject sensitive values at runtime using dedicated secret mechanisms.

Problem

Dockerfiles store potential secrets in ENV keys. This exposes sensitive data in the image.

Description

Values declared with ENV are persisted in image metadata and can be recovered from image history, registry copies, or downstream runtime inspection. This creates long-lived exposure for credentials, API tokens, or internal endpoints that should remain secret.

The risk compounds when images are shared across environments. A single leaked build artifact can expose the same secret in development, staging, and production. Secret rotation then becomes expensive and urgent because the value may already be cached in multiple registries and pipelines.

Related rules: avoid ARG vars in RUN commands, avoid default or root user, avoid piping curl into shell.

Solution

Remove secret values from ENV. Inject sensitive data at runtime using secret stores, orchestrator secret objects, or Docker build/runtime secret mechanisms designed for non-persistent handling.

Problematic code

FROM ubuntu:20.04
USER nobody
ENV PASSWORD=supersecret123

Verified code

FROM ubuntu:20.0
USER nobody
# Remove sensitive data from the Dockerfile.
# Inject PASSWORD at runtime using secure methods.

Source of the description

Docker Build secrets