Rules / GL059

GL059 docker build --build-arg with a secret-like value

Severity: warn
OWASP: CICD-SEC-6 – Insufficient Credential Hygiene
CWE: CWE-532 – Insertion of Sensitive Information into Log File

Risk

Passing secrets via docker build --build-arg bakes them into the image's layer metadata. Even if the final image doesn't expose the value at runtime, docker history --no-trunc reveals all build arguments in plaintext. Any party with read access to the image — the registry, a CI artifact store, a colleague pulling the image — can extract the secret.

This is a common pattern developers use to inject API keys, tokens, or passwords into the build process without realising the value persists in the image.

Trigger example

build:
  script:
    - docker build --build-arg NPM_TOKEN=$NPM_TOKEN -t myapp .

Flagged when the build-arg name contains a secret keyword (TOKEN, SECRET, PASSWORD, PASS, KEY, CREDENTIAL, AUTH) as an underscore- or boundary-delimited token. Generic args like --build-arg VERSION=1.0 or --build-arg BYPASS_CACHE=true are not flagged.

Safe alternative

Use Docker BuildKit secret mounts — the secret is available during build but never written to any layer:

build:
  script:
    - echo "$NPM_TOKEN" > /tmp/npm_token
    - docker build --secret id=npm_token,src=/tmp/npm_token -t myapp .
    # In Dockerfile: RUN --mount=type=secret,id=npm_token npm install

Notes

• Severity is warn — the value may already be non-sensitive, but a secret-keyword build-arg name is a strong signal.
• Detection is name-based and value-agnostic: both --build-arg API_KEY=$API_KEY and --build-arg API_KEY=literal are flagged.
• Related: GL006 (hardcoded secrets in variables:), GL021 (secret printed to log).
• Script-line rule; assumes POSIX shell (see the README Shell assumptions note).
• Suppress per-file with .glsec-ignore or inline # glsec:ignore GL059.

Documentation for glsec 1.23.0. Source of this page · Rule implementation