They often treat ENV and ARG as convenient placeholders, but both can expose secrets in image metadata and history. That creates durable leakage even when the final container no longer appears to contain the value. Teams should reserve these instructions for non-sensitive parameters and use safer secret injection methods for credentials.
Why This Matters for Security Teams
Using ENV and ARG for credentials creates a security problem that is easy to miss during code review and painfully durable after deployment. Build-time values can land in image layers, cached build output, logs, and metadata, which means a secret can survive long after the final running container looks clean. That matters because container builds are often copied into registries, shared across environments, and reused by CI/CD pipelines.
Security teams usually underestimate the blast radius. A credential used once in a build can become visible to anyone with access to the image, build cache, or pipeline artifacts, which turns a short-lived convenience into a long-lived exposure. This is why NIST SP 800-53 Rev 5 Security and Privacy Controls remains relevant: it reinforces the need to protect secrets, enforce least privilege, and limit unauthorized disclosure across the delivery chain. The same logic applies to cloud-native identity assets, which is why the OWASP Non-Human Identity Top 10 is increasingly useful for containerized systems that rely on service credentials, API keys, and build automation identities.
In practice, many security teams discover the problem only after a registry audit, pipeline incident, or secret rotation event reveals that the old credential still exists in build history rather than through intentional secret handling.
How It Works in Practice
Docker and similar build systems treat ARG as a build-time input and ENV as an image-level environment variable. Neither is designed as a secret container. If a sensitive value is passed through either mechanism, it can be preserved in layers, accessible through image inspection, surfaced in build logs, or inherited by downstream stages. Even when a multi-stage build removes the final artifact, the earlier stage may still have exposed the value during execution.
Practitioners should separate parameter types. Non-sensitive build parameters such as version numbers, feature flags, or target paths can safely use ARG or ENV. Credentials should instead be injected through secret-aware build features, runtime secret mounts, or external secret managers. The key test is simple: if a value would be damaging to disclose later, it should not be embedded in a layer or build record.
- Use
ARGonly for non-sensitive build inputs that do not require confidentiality. - Use
ENVfor application defaults, not for credentials or tokens. - Prefer build-time secret mounts or external secret retrieval for private package registries, signing keys, and API access.
- Rotate any credential that may already have appeared in a build pipeline, cache, or registry.
Identity governance matters here too. Build pipelines often act as non-human identities with broad access to registries, artifact stores, and cloud APIs, so credential handling should be evaluated as part of NHI control design. The operational baseline should also align with identity assurance principles in the NIST SP 800-63 Digital Identity Guidelines when those build identities are issued, authenticated, and monitored. These controls tend to break down when legacy CI systems lack secret-mount support because teams compensate by hardcoding values into build arguments.
Common Variations and Edge Cases
Tighter secret handling often increases pipeline complexity, requiring organisations to balance stronger confidentiality against build portability and developer convenience. That tradeoff is real, especially in older build systems where secret-aware features are limited or inconsistent.
Current guidance suggests treating the following cases differently:
- Public values like version labels or package mirrors can remain in
ARG. - Environment defaults for application behaviour can remain in
ENVif they are not sensitive. - Credentials used only during package installation, signing, or test data access should be supplied through ephemeral secret channels.
- Third-party build plugins deserve extra scrutiny because they may echo variables into logs or preserve them in artifacts.
There is no universal standard for every build platform yet, but the best practice is consistent: secret handling should be explicit, short-lived, and excluded from image provenance wherever possible. Teams should also treat container build credentials as part of broader secret governance, not as a one-off Docker concern. Where regulated environments are involved, secret exposure can also implicate policy obligations around access control, auditability, and data minimisation under NIST control expectations.
For practitioners mapping this into operational security, the important question is not whether the final container can run, but whether the credential could still be recovered from the build chain after the fact. That is the failure mode that matters most, and it is still missed in many fast-moving CI/CD environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Build secrets require controlled access and identity governance across pipelines. |
| OWASP Non-Human Identity Top 10 | NHI-01 | CI/CD systems act as non-human identities that often mishandle credentials. |
| NIST SP 800-63 | AAL2 | Pipeline identities need strong authentication when they can mint or retrieve secrets. |
Use strong authentication and monitored service identities before allowing secret access in builds.
