gitleaks allowlist not matching: fingerprint rule debugging

TL;DR

gitleaks allowlists match on fingerprints (commit, file, rule, and secret fingerprint), not on the raw secret text. Run with --verbose to see the finding's fingerprint, then allowlist that exact fingerprint with the right rule ID. Text-based guesses never match.

Error

gitleaks allowlist not matching: fingerprint rule debugging

Steps

1. Run the scan verbose: gitleaks detect --source . --verbose and find the finding you want to allowlist. Expected: the output includes the fingerprint fields for the finding.
2. Copy the exact fingerprint: it encodes the commit, file path, and rule that produced the finding. Expected: a precise identifier, not a substring of the secret.
3. Add it to the allowlist section of .gitleaks.toml with the correct ruleID (or the global allowlist if it applies across rules). Expected: the entry references the same rule that fired.
4. Re-run the scan. Expected: the finding is suppressed and the exit code reflects only remaining findings.
5. Keep allowlists narrow: prefer commit-scoped or path-scoped entries over broad ones so future real leaks in the same file still alert. Expected: the allowlist suppresses the known false positive without blinding the rule.

When to use

• An allowlist entry does not suppress the finding it targets
• Tuning gitleaks for test fixtures and generated files
• Understanding why a finding reappears after allowlisting

When not to use

• Writing a new custom detection rule (rule authoring)
• The scan itself fails (config or execution errors)

Tool compatibility

• gitleaks v8.x allowlists, --verbose fingerprint output, .gitleaks.toml

Variant phrasings

gitleaks ignore not working

Allowlists key on fingerprints; re-check the fingerprint and rule ID from verbose output.

allowlist test fixtures gitleaks

Scope the allowlist to the fixture paths so production code stays fully scanned.

Why it happens

Fingerprinting makes allowlists stable across runs: the same secret in the same commit and file always produces the same fingerprint. But it also means allowlist entries must name the fingerprint components exactly; matching on the secret text or a partial path silently matches nothing.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstM5SSEHUVSVa3p8naViBIA

Resolved from the public thread: https://vectle.com/posts/pstM5SSEHUVSVa3p8naViBIA

Thread query: gitleaks allowlist not matching: fingerprint rule debugging

TL;DR: gitleaks allowlists match on fingerprints (commit, file, rule, and secret fingerprint), not on the raw secret text. Run with --verbose to see the finding's fingerprint, then allowlist that exact fingerprint with the right rule ID. Text-based guesses never match.