How to Scan Docker Images for Hardcoded Secrets

What this check reads

The check takes the first 5 tagged local images, <none> entries excluded, then branches on whether trivy is installed. With trivy it runs trivy image --quiet --scanners secret --format json --timeout 120s <img> against each one and marks the image when the JSON contains "Class":"secret"; a single marked image is the FAIL and none across the sample is the only PASS this check can produce. Without trivy it greps docker history --no-trunc <img> for AWS_SECRET|PRIVATE KEY|PASSWORD=|API_KEY|SECRET_KEY and WARNs whichever way that goes, because build-command text is all that branch can see.

The trivy branch does not work as intended today. Trivy pretty-prints its JSON with a space after the colon ("Class": "secret"), so the compact pattern never matches and no image is ever marked. With trivy installed the check currently returns PASS whatever the layers contain.

When it applies

Needs the docker binary and daemon access; otherwise SKIP. It examines the first 5 tagged local images. Which branch runs depends entirely on whether trivy is installed:

• With trivy - a real secret scan of layer contents (--scanners secret), 120-second timeout per image. This is the only branch that can PASS.
• Without trivy - a much weaker fallback that greps docker history text for AWS_SECRET|PRIVATE KEY|PASSWORD=|API_KEY|SECRET_KEY. It only sees build-command text, never file contents, so a secret in a COPYd file is invisible. Both outcomes of this branch are WARN, including the "looks clean" one - deliberately, because nothing was really verified.

What each result means

Why it matters

Anything copied into a layer stays in the image even if a later RUN rm removes it; docker history and layer extraction recover it. Build-time ARG/ENV values are recorded in image metadata. CIS Docker 4.10 "Ensure secrets are not stored in Dockerfiles"; OWASP Docker Cheat Sheet Rule #12 (secrets); OWASP Secrets Management Cheat Sheet; NIST SP 800-190 4.1.2 "Image configuration defects / embedded secrets".

Why it fails, and when it is wrong

• The trivy match never fires (known issue). The script greps for "Class":"secret" with no space, and trivy writes "Class": "secret". An image with a private key in a layer returns PASS. Read trivy's own output, not this verdict.
• Trivy flags test fixtures, example keys and placeholders in vendor packages; check the Title/Match in the JSON before rotating anything.
• Trivy secret scanning can be slow on large images (walks every file) → timeout → empty output → silently treated as no secrets for that image (the script does not distinguish timeout from clean). Run manually with a longer --timeout.
• The fallback history grep only sees RUN/ENV command text, not file contents.
• Secrets injected at run time via env vars are covered by Secrets In Env, not here.

How to fix it

trivy image --scanners secret <image>
docker history --no-trunc <image> | grep -iE 'AWS_SECRET|PRIVATE KEY|PASSWORD=|API_KEY|SECRET_KEY'

# syntax=docker/dockerfile:1
RUN --mount=type=secret,id=npmrc,target=/root/.npmrc npm ci

docker build --secret id=npmrc,src=$HOME/.npmrc -t app:1.4.3 .

Verify the fix

# The real scan, across every image rather than the first five:
for i in $(docker images --format '{{.Repository}}:{{.Tag}}' | grep -v '<none>'); do
  echo "== $i"; trivy image --quiet --scanners secret "$i"
done
# expected: no secret findings

# Manual inspection of build history (what the fallback sees):
docker history --no-trunc <image> | grep -iE 'AWS_SECRET|PRIVATE KEY|PASSWORD=|API_KEY|SECRET_KEY'

# And of the layers themselves (what it does not):
docker save <image> | tar -tv | head

Debugging

Sources

• Docker: Build secrets (--mount=type=secret)
• Docker: Multi-stage builds
• Docker: .dockerignore
• Trivy: Secret scanning
• Docker: docker history
• OWASP Secrets Management Cheat Sheet

How the script reads this