Git Secrets Scanner
Deleting a key from the code does not delete it from the repository. This scanner searches the files at HEAD, then the lines added by past commits, then the names of files ever committed. A secret removed long ago is still reported, tagged with the commit that added it.
A secret that left HEAD
The scanner works on a clone and uses git directly. It runs three passes in a fixed order and does not de-duplicate between them, so one secret can be reported by more than one pass. The example is the common mistake: a key committed in one commit and deleted in the next.
1Commit a1f3 added .env with a live Stripe key. Commit 9c0d deleted it. Anyone who clones the repository still gets a1f3, so the key is one git show away.
2Pass 1 reads the files at HEAD. Every indexed file except lock files, *.min.js and node_modules/ goes through the thirteen patterns. app.js is clean, so nothing is reported yet.
3Pass 2 reads the lines that past commits added. git log --all --diff-filter=A -p hands over the diff of a1f3. The Stripe pattern matches, the finding carries the commit hash, and because the file is not at HEAD the description says the secret "may still be valid if not rotated". Confidence 0.90.
4Pass 3 looks only at file names. .env matches one of five patterns (.env and its .local/.production/.staging variants, .pem, .key, credentials.json, service-account JSON), giving a HIGH finding at 0.95 even if the file held no recognisable key. One finding per file name.
5Nothing at HEAD, two findings. A secret that is still in HEAD would additionally be reported by pass 1 as "currently in the codebase".
Which patterns match
Every pass ends in the same function: run each of the thirteen regexes over a block of text, drop matches shorter than 8 or longer than 500 characters, mask the value and emit a finding. The table of patterns is fixed in the scanner's configuration; there is no entropy scoring in the matching path.
1One block of added lines meets the thirteen patterns. Six critical (red) and seven high (amber) shapes are defined, covering Stripe, AWS, GitHub, OpenAI, Anthropic, Firebase, SendGrid, Twilio, database URLs, private keys and Supabase-style JWTs.
2An AWS access key ID is the literal AKIA followed by sixteen uppercase letters or digits. Match: CRITICAL, confidence 0.90.
3A postgres://, postgresql://, mysql://, mongodb:// or mongodb+srv:// URL matches up to the next whitespace or quote, password included. CRITICAL when it embeds a real user:password@ (the password may contain /) or a password=/pwd= query parameter. A URL with no password or a templated one (${DB_PASS}) is not reported; an obvious placeholder password such as password drops to MEDIUM.
4The "Supabase service role key" pattern is eyJ….eyJ….sig, and the payload's role claim is then decoded. service_role is CRITICAL. The public anon key that ships in every frontend is not reported, and a JWT whose role cannot be confirmed is kept at MEDIUM instead of being dropped.
5A Stripe live secret key is sk_live_ plus at least 24 letters or digits. The pattern is live keys only: a sk_test_ key does not match.
6Plain assignments never match: the two ordinary lines stay silent because only these shapes are searched, and a variable named SECRET or PASSWORD with a weak value is invisible. Matches are masked before they are stored: first 8 characters, ***, last 4.
What the history pass sees
The history pass does not ask git for every change. It asks for --diff-filter=A, which keeps only the files a commit adds. That choice decides which commits are readable. This was confirmed on a scratch repository: a key appended to an existing file in a later commit never appeared in the output.
1Five commits touch a key. In c2 it is appended to an existing file; in c4 it arrives in a new file. Both were later removed.
2The history pass runs git log --all --diff-filter=A -p --no-merges. Only file additions carry a diff, so the scanner reads c1 and c4. It collects the lines starting with + per file and scans them.
3c4's added lines contain an AKIA… key: one CRITICAL finding with the commit hash. c1 holds only x=1.
4The key in c2 is never read. A modification is not an addition, so the diff is filtered out. Modified files are therefore not covered by the history pass, which looks like a gap in the scanner rather than intended behaviour.
5The pass is also bounded: the last 500 commits, no merge commits, a file diff over 1 MB is skipped whole, and git gets 60 seconds. If git fails or times out the pass logs a warning and returns what it has.
For a history finding the scanner asks whether the file path exists in the HEAD index, not whether the secret is still in it. If config.js held a key in an old commit and the file still exists today without it, the finding says "this secret is currently in the codebase". The tag is a statement about the file, so read the commit hash before concluding the key is live.
The fix: rotate first
Because a clone carries the whole history, the only repair that works on every copy is to make the leaked value worthless.
1The Stripe key from the earlier example is still live in a1f3. Deleting .env in 9c0d changed nothing for a cloner.
2Rotate it. Issue a new key and put it in the environment. The old string in history now authenticates nothing. This is the one step that cannot be skipped.
3Rewriting history is optional and destructive. git filter-repo --path .env --invert-paths drops the file from every commit, but existing clones and forks keep their copies, which is why rotation comes first.
4Put .env in .gitignore, read secrets from process.env, and run gitleaks as a pre-commit hook so the next key never reaches a commit.
Why it matters
Exposed secrets are the fastest path to a full compromise. A database connection string gives direct read and write access; leaked AWS keys can create resources, read S3 buckets and delete infrastructure; an API key lets an attacker act as your application; a Supabase service role key bypasses every Row Level Security policy. The secret does not need to be in today's code. If it was ever committed, anyone who clones the repo can run git log -p and find it.
Uber engineers committed AWS credentials to a private GitHub repository. Attackers found them, opened an S3 bucket and stole 57 million user and driver records; Uber paid $100K to the attackers and concealed the breach for over a year. In 2022, GitGuardian researchers found Samsung engineers had leaked internal source code, private keys and AWS credentials in public GitLab repositories.
Vulnerable vs fixed code
// BAD: hardcoded secret in source code
const STRIPE_SECRET = "sk_live_51abc123def456..."
// BAD: committed .env file
// .env
SUPABASE_SERVICE_ROLE_KEY=eyJhbGciOiJIUzI1NiIs...
DATABASE_URL=postgresql://user:p@ssw0rd@db.example.com/prod
// BAD: "removed" secret, still in git history
// commit abc123 "add config" then commit def456 "remove secrets"
// still recoverable with: git show abc123:.env# 1. Rotate the secret immediately (the only real fix)
# 2. Keep the file out of git
echo ".env" >> .gitignore
// 3. Read it from the environment, not the code
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!)
# 4. If it was committed, rewrite history (destructive)
pip install git-filter-repo
git filter-repo --path .env --invert-paths
# 5. Block the next one with a pre-commit hook
# - repo: https://github.com/gitleaks/gitleaks
# hooks: [{ id: gitleaks }]Limits and configuration
| Setting | Value | Effect |
|---|---|---|
| Commits scanned | 500, --no-merges | Older commits and merge commits are never read |
| Diff size | 1 MB of added text per file per commit | Larger diffs are skipped whole |
git log timeout | 60 s | Timeout is logged; findings from other passes remain |
| Match length | 8 to 500 characters | Shorter or longer matches are dropped |
| Skipped files | package-lock.json, yarn.lock, pnpm-lock.yaml, *.min.js, node_modules/ | Never scanned at HEAD or in history |
| Confidence | 0.90 for a pattern match, 0.95 for a sensitive file name | Fixed values |
| Severity | Critical: Supabase service_role JWT, Stripe live secret, AWS, GitHub PAT, database URL, private key. High: Stripe restricted, GitHub OAuth, OpenAI, Anthropic, Firebase, SendGrid, Twilio, sensitive file names | Set by the pattern |
The pattern table has no Stripe sk_test key, no GitLab token and no "high-entropy string in a variable assignment" detection: only sk_live_ and rk_live_ Stripe keys, no GitLab pattern, and the entropy helper in the scanner is defined but never called. The history pass reads added files only (see above), and the Supabase pattern matches any three-part JWT. There is no de-duplication, so a secret still at HEAD can be reported by pass 1 and again by pass 2. The scanner needs a clone with a .git directory and sends nothing over the network.