Rule Information
Tags
dockerdockerfilesecretscredentialssecurityargbuild-argpasswordtokenapi-keysensitive-datainformation-disclosure
CWE References
Interactive Playground
Experiment with the vulnerable code and security rule below. Edit the code to see how the rule detects different vulnerability patterns.
pathfinder scan --ruleset docker/DOCKER-SEC-005 --project .1
2
3
4
5
6
7
8
9
10
11
rule.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
About This Rule
Understanding the vulnerability and how it is detected
This rule detects ARG instructions with names that suggest they contain sensitive information such as passwords, API keys, tokens, or credentials. Build arguments are permanently stored in the Docker image metadata and can be retrieved by anyone with access to the image using 'docker history', making them unsuitable for secrets.
Security Implications
Potential attack scenarios if this vulnerability is exploited
1
Persistent in Image Layers
ARG values are baked into the image metadata and remain accessible even if the layer is deleted or the secret is "removed" later
2
Visible in Image History
Anyone with access to the image can run 'docker history' or 'docker inspect' to retrieve all build arguments
3
Supply Chain Exposure
Images pushed to registries expose these secrets to anyone who pulls the image
4
No Encryption
Build args are stored in plaintext within the image metadata
5
CI/CD Leakage
Build logs often echo ARG values, exposing them in CI/CD systems Real-world attack scenario: - Developer passes database password as build arg: --build-arg DB_PASSWORD=secret123 - Image is pushed to Docker Hub or private registry - Attacker pulls image and runs: docker history image:tag --no-trunc - Attacker extracts DB_PASSWORD from build history - Attacker uses credentials to access production database
How to Fix
Recommended remediation steps
- 1Use Docker BuildKit secret mounts instead of ARG for secrets
- 2Store secrets in environment variables at runtime, not at build time
- 3Add sensitive files to .dockerignore to prevent accidental inclusion
References
External resources and documentation
Similar Rules
Explore related security rules for Docker
MEDIUM
Sudo Usage in Dockerfile
Dockerfile uses sudo in RUN instructions. This is unnecessary during build (already root) and increases security risk if sudo remains in the final image. Use USER instruction for privilege changes instead.
HIGH
Container Running as Root - Missing USER
Dockerfile does not specify USER instruction. Container will run as root by default, which increases the attack surface if the container is compromised.
CRITICAL
Docker Socket Mounted as Volume
Dockerfile mounts Docker socket. This gives the container full control over the host Docker daemon, equivalent to root access.
Frequently Asked Questions
Common questions about Secret in Build Argument
ARG values are stored in the image layer history. Anyone with access to the image can run docker history to see all build arguments including secrets.
Use BuildKit secret mounts: RUN --mount=type=secret,id=mysecret cat /run/secrets/mysecret. The secret is available during build but never stored in a layer.
Run docker history --no-trunc <image> to inspect all layers. Tools like trufflehog and gitleaks can also scan container images for exposed credentials.
New feature
Get these findings posted directly on your GitHub pull requests
The Secret in Build Argument rule runs in CI and posts inline review comments on the exact lines — no dashboard, no SARIF viewer.