DOCKER BUILD SECRETS CHECK · RUNS IN YOUR BROWSER

Is a secret baked into your Docker image?

An ENV or ARG instruction with a secret-looking name is, per Docker's own "Build secrets" documentation, present in the final image and viewable by anyone with access to it via docker history or docker inspect — whether the value is a literal string or resolved from a build argument. Paste your Dockerfile below and this page finds every instruction that risks that, plus any COPY/ADD of a well-known credential file, with the BuildKit build-secret fix for each.

Nothing is uploaded. The Dockerfile you paste is read in this browser and never leaves your device, and this tool makes no network calls of its own.

1. Paste one or more Dockerfiles

Copy the contents of each Dockerfile (or Dockerfile.* / *.dockerfile) you want checked. Add more blocks for more files — nothing here reads your repository, so pasting is how it sees anything.

Paste at least one Dockerfile above and click Check.

Prefer a CLI, or want this in your own CI?

Same logic, zero dependencies, one file:

python3 check.py                  # scan every Dockerfile under the current directory
python3 check.py /path/to/repo    # scan a specific checkout
python3 check.py --format json    # machine-readable
python3 check.py --fail-on-risk   # exit 2 if any high-risk finding is found

Get check.py from the repo — stdlib only, nothing to install, no network calls. Wire --fail-on-risk into your own CI to block a newly-added secret-looking ENV or a copied credential file before it merges.

Common questions

Why is an ENV instruction with a secret-looking name a risk?

Docker's own "Build secrets" documentation states it directly: passing a secret through ARG or ENV "is not recommended, since this data is present in the final image" and can be viewed by anyone with access to it using docker history or docker inspect. That is true whether the ENV value is a literal string in the Dockerfile or resolved from a build argument (ARG TOKEN, then ENV TOKEN=$TOKEN) — either way, the resolved value is written into the image's config layer and stays there even if a later instruction deletes the file it came from.

Does this tool verify that a flagged name actually holds a secret?

No, and it cannot. This is a name-pattern heuristic over Dockerfile text, not a value scanner — it never sees what a build actually resolves ARG or ENV to. A name like API_KEY is flagged because it looks like a secret, even if the value behind it is a public, non-sensitive identifier; a genuine secret under an unrecognised name is a false negative this tool cannot close. Read every finding and use your own judgment.

What is the difference between the three finding types?

env-secret and sensitive-copy are flagged unconditionally: an ENV value is always baked into the image config, and a copied credential file persists in its layer even after a later instruction deletes it. arg-literal means a secret-looking ARG carries a default value written directly in the Dockerfile — committed to source control. arg-declared is advisory only: a bare ARG with no default commits nothing to the Dockerfile itself, but invites a caller to pass a secret with --build-arg, which BuildKit still records for the build unless it is mounted as a build secret instead.

Does this tool fetch or send anything anywhere?

No. It makes no network calls of any kind — nothing here can, because nothing here talks to a registry, a secrets manager, or any API. The Dockerfile text you paste is read entirely in this browser tab and never leaves your device.

More: how to pass a Docker build secret without baking it into the image. Already run gitleaks? See how this checker compares for the Dockerfile-instruction question specifically, or see how it compares to reading a Dockerfile by hand.