Docker Build Secrets Check vs. gitleaks
Related tools, different jobs. gitleaks is a general secret scanner: regex and entropy over tracked files, with no idea that a Dockerfile ENV always bakes its resolved value into the image config regardless of that value's shape. This page checks the Dockerfile-instruction question directly, free, in your browser, with no install.
What each tool is for
gitleaks (github.com/gitleaks/gitleaks) is an open-source secret scanner
that, per its own public documentation, walks a git repository's history and working tree (or an arbitrary
directory) looking for values matching a configurable set of regex and entropy rules, across every file
type it is pointed at -- not specific to Dockerfiles or any other single format. It runs as a CLI, a
pre-commit hook, or a CI action.
This checker does one narrower thing: you paste the text of a Dockerfile, and it lists
every ENV or ARG instruction whose name looks like a secret, and every
COPY/ADD naming a well-known credential file (.env,
id_rsa, .npmrc, .aws/credentials, ...) -- with the exact BuildKit
--mount=type=secret fix for each. It understands what a Dockerfile instruction actually does:
an ENV NAME=$ARG_REF line carries no literal secret text for a regex to match, and a bare
ARG SIGNING_TOKEN declaration has no value in the file at all, yet both are flagged here
because the risk is in what the instruction does at build time, not in what the line looks like. It runs
entirely in your browser, needs no install, and makes no network call of its own.
| Question | Where to answer it |
|---|---|
| Does my whole repository, across its full git history, contain any secret-shaped string in any file? | gitleaks -- that is its entire job, and this tool does not attempt any of it. |
| Does my Dockerfile bake a secret into the image via ENV or a literal ARG default, or copy in a credential file, regardless of whether that value is literal text a regex could match? | This checker -- a file:line list of the specific Dockerfile instructions at risk, with a BuildKit fix for each. |
My Dockerfile has ARG SIGNING_TOKEN with no default at all -- is that a risk? | Only this checker flags it: there is no secret-shaped text on that line for a regex scanner to match, but the bare declaration still invites an unsafe --build-arg at build time. |
| I want this wired into CI to block a merge automatically. | Either: gitleaks' own CI integration for repository-wide secret scanning, or this tool's check.py --fail-on-risk for the Dockerfile-instruction question specifically. |
The two are complementary, not competing: a repository can run gitleaks for the broad, repository-wide scan it is built for and still reach for this tool for the Dockerfile-instruction question gitleaks has no way to ask.
Common questions
Should I use this checker or gitleaks?
Different shapes of tool for a related but different question. gitleaks is a general-purpose secret scanner -- per its own public documentation, it walks a git repository's history and working tree (or an arbitrary directory) looking for values that match a configurable set of regex and entropy rules, across every file type, not just Dockerfiles. This tool checks Dockerfile instructions specifically: whether an ENV or ARG name looks like a secret, and whether a COPY or ADD names a well-known credential file, regardless of whether the value behind that name is present in any git-tracked file at all. If you want broad secret detection across an entire codebase and its history, gitleaks is built for exactly that and this tool does not attempt it. If you want the specific answer to "does this Dockerfile bake a secret into docker inspect, or copy a credential file into a layer," this is the narrower, Dockerfile-aware tool for that question.
Wouldn't gitleaks already catch a secret in a Dockerfile?
Only the shapes its regex and entropy rules are built to catch, and only where it looks. A literal high-entropy value in a Dockerfile line, like ARG API_KEY=sk_live_abc123..., is exactly the kind of value gitleaks' rules are designed to find. What a general text scanner has no way to know, because it is not aware of Dockerfile instruction semantics, is that an ENV instruction bakes its resolved value into the image's config layer regardless of the value's shape -- a value assigned from a build argument (ENV TOKEN=$TOKEN) carries no literal secret text in the Dockerfile line itself for a regex to match, and a bare ARG SIGNING_TOKEN declaration with no default has no value in the file at all, yet both are real exposure risks this tool flags specifically because it understands what each Dockerfile instruction does. And a secret scanner walking a git repository has nothing to scan if the credential file a COPY instruction names, such as a local .aws/credentials, is itself untracked or gitignored -- present on disk, absent from the history a repo-scanner reads.
Why would I need a separate checker if gitleaks already exists?
Two reasons. First, the coverage gap above: gitleaks looks for secret-shaped text, and this tool's entire reason to exist is the instruction-level question a text scan cannot ask -- does this ENV or ARG bake a value into the image regardless of its shape, and does this COPY name a credential file regardless of whether that file's contents are scannable at all. Second, gitleaks is a Go binary you install and run against a repository; this tool is also available as a page you open with nothing to install, for a quick check on a single Dockerfile you have not wired into a scanner yet. Neither point is a criticism of gitleaks' own scope -- general secret scanning across an entire codebase is a different, and broader, job than this tool attempts, which is exactly why a narrower, Dockerfile-aware check is worth having alongside it.
Is this page affiliated with gitleaks?
No. This site is not affiliated with, endorsed by, or sponsored by the gitleaks project or its maintainers. gitleaks is an open-source secret scanner, named here only to describe what this checker is and is not, using facts drawn from its own public documentation and source repository at github.com/gitleaks/gitleaks.