Using ENV and ARG instructions in a Dockerfile to handle secrets can expose sensitive information through the image metadata, container environment, or build logs.

Why is this an issue?

The ARG and ENV instructions in a Dockerfile configure the image build and the container environment respectively. When either instruction is used to pass secrets, traces of those values are typically retained — in the image layer history, the container environment, or the build logs. Any party that gains access to the image or its build history can retrieve these values.

What is the potential impact?

The concrete impact depends on the nature of the exposed secret:

• Financial damage can occur if a paid service API key is disclosed and used without authorization.
• The application can be fully compromised if an application secret such as a session signing key is exposed.
• Full infrastructure takeover becomes possible if a system secret such as a remote access key is leaked.

How to fix it

Code examples

Noncompliant code example

FROM example
ARG ACCESS_TOKEN # Noncompliant
ENV ACCESS_TOKEN=${ACCESS_TOKEN} # Noncompliant
CMD /run.sh

Compliant solution

For runtime secrets, leave environment variables empty in the Dockerfile and inject their values at container start. Store secrets in an environment file and start the container with the --env-file argument:

FROM example
ENV ACCESS_TOKEN=""
CMD /run.sh

docker run --env-file .env myImage

For build-time secrets, use Buildkit’s secret mount type instead:

FROM example
RUN --mount=type=secret,id=build_secret ./installer.sh

Resources

Documentation

• Dockerfile reference - ENV command
• Dockerfile reference - ARG command
• Dockerfile reference - RUN command secrets mount points
• Docker documentation - Manage sensitive data with Docker secrets

Standards

• CWE - CWE-522 - Insufficiently Protected Credentials