gitleaks .gitleaksignore fingerprint not honored in CI

gitleaks ignores a finding by its exact fingerprint (commit:file:rule:line). If any part of that fingerprint changes, the old .gitleaksignore line no longer matches and the finding fails again.

What this error means

A finding you already added to .gitleaksignore reappears and fails the build after a rebase, a file move, or a line-number shift. The rule and value look identical.

Finding:     generic-api-key
Fingerprint: 7c1e...:config/app.py:generic-api-key:42
9:31AM WRN leaks found: 1
# .gitleaksignore had 3f2a...:config/app.py:generic-api-key:39  (stale)

Common causes

The fingerprint changed after a rebase or edit

The fingerprint embeds the commit SHA and line number; a rebase rewrites the SHA and edits shift the line, so the recorded fingerprint is stale.

The .gitleaksignore is not at the scan root

gitleaks reads .gitleaksignore from the source root by default; if the file lives elsewhere and no path is passed, the entries are not applied.

How to fix it

Regenerate the fingerprint and update the ignore file

1. Copy the current Fingerprint: line from the failing finding.
2. Replace the stale entry in .gitleaksignore with the new fingerprint.
3. Commit .gitleaksignore at the repo root so the scan picks it up.

# .gitleaksignore  (one fingerprint per line)
7c1e0a...b9:config/app.py:generic-api-key:42

Prefer an allowlist for durable exceptions

A path or regex allowlist in .gitleaks.toml survives rebases and line moves, unlike a per-commit fingerprint.

[allowlist]
regexes = ['''EXAMPLE_[A-Z0-9]{20}''']

How to prevent it

• Use config allowlists for stable exceptions, fingerprints only for one-offs.
• Regenerate fingerprints after a history rewrite.
• Keep .gitleaksignore at the repo root passed to the scan.

Related guides