← Back to Terraform Plan Secret Exposure Check
Gitleaks is a widely used, general-purpose secret
scanner: point it at a git repository (it can walk the full commit
history via git log -p), a directory, a single file, or
piped stdin, and it flags secret-shaped strings using configurable
regex rules and entropy scoring, including inside archives
(zip, tar, gzip) and encoded
content (base64, hex, percent-encoding). It has no built-in parser for
Terraform's plan format, so pointed at a terraform show -json
file it scans the JSON the same way it would scan any other text file
— by pattern and entropy, not by understanding the plan's own
before_sensitive/after_sensitive structure.
This tool does the opposite trade: it reads only one file — your structured plan — and asks one narrow, schema-aware question per attribute: did Terraform's own provider schema already mark this sensitive, and if not, does the value match one of four fixed, high-confidence secret shapes (an AWS access key, a PEM private key, a JWT, or a URL with embedded credentials)? It is not a general secret scanner, does not read git history, and will not catch a secret committed in a variables file, a script, or a README — that is exactly the job Gitleaks and similar repository scanners are built for.
| Question | Where to answer it |
|---|---|
| I want my whole repository, including git history, scanned for anything that looks like a hardcoded secret — API keys committed by accident, tokens left in old commits, credentials in config files. | Gitleaks — that is its core job, and it is built to run across a full checkout or history, not one plan file. |
I want to know specifically whether Terraform's own sensitive flag missed an attribute on the plan about to be applied, without re-reading a config-wide scan's output to find the one relevant hit. |
This checker — it reads the plan's own sensitivity map and reports only the attributes Terraform itself did not already mark, against four fixed secret shapes. |
I want a pre-apply CI gate with zero dependencies to install or a config file (.gitleaks.toml) to maintain. |
This checker — one Node file, no install, no rules to tune. (Gitleaks ships sensible defaults too; the difference here is there is nothing to configure at all.) |
| I want the report to redact the matched value so it is safe to paste into an issue or a CI annotation. | This checker — every finding shows only the first and last four characters. Check your Gitleaks configuration and output format if you rely on it for the same guarantee; its default reporting is not built around that specific use case. |
| I want broad, mature, actively maintained secret detection across many source types (files, archives, stdin, CI logs piped in) with a large, configurable rule set. | Gitleaks — it is the established, general-purpose tool for exactly that breadth. |
The honest read is that these solve adjacent, not identical, problems,
and a pipeline that both generates and applies Terraform plans has
good reason to run both: Gitleaks over the repository in general, and
this checker as the one gate that understands Terraform's own
sensitive mechanism well enough to say precisely which
attribute the schema forgot to flag, right before the plaintext value
would otherwise print into the apply log. Neither replaces careful
review of what a provider schema actually marks sensitive in the
first place.
They catch different things and are not a substitute for each other. Gitleaks is a general-purpose secret scanner: point it at a git repository, a directory, a file, or stdin, and it looks for secret-shaped strings using regex rules and entropy scoring, including inside git history and archives. It has no built-in awareness of Terraform's own before_sensitive/after_sensitive plan structure, so run against a plan file it treats the JSON as plain text like any other file. This tool reads exactly one file — the structured plan from terraform show -json — and checks only the attribute values Terraform's own schema did not already mark sensitive, against four fixed high-confidence secret shapes. A CI pipeline that applies Terraform plans commonly wants both: Gitleaks for the repository and its history in general, this tool as a narrow pre-apply gate for the one failure mode neither a generic scanner nor a code reviewer can see — a provider schema that quietly forgot to flag an attribute as sensitive.
It can catch the resulting plaintext value if that value matches one of its configured detection rules or trips its entropy threshold — Gitleaks does not read or parse Terraform's plan format specially, so it is scanning the JSON as generic text, the same way it would scan any file. It has no concept of Terraform's own sensitive marking, so it cannot tell you specifically that the provider schema failed to flag an attribute — only that some string in the file looked secret-shaped (or, for a value that does not match its rules, nothing at all). This tool's whole job is that one narrower question: does the plan's own before_sensitive/after_sensitive map already exclude this value, and if not, does it match one of four fixed shapes.
No. This site is not affiliated with, endorsed by, or sponsored by Gitleaks or its maintainers. Gitleaks is a trademark of its owner, named here only to describe what this checker is and is not, based on Gitleaks' own public description of its scanning scope.
See also why a Terraform plan can print a secret even though the schema has a sensitive flag, or open the checker itself to try it on a plan.