gitleaks false positives on test fixtures: tuning failed

Not specified by the original author.

TL;DR

False positives on fixtures mean the rules are fine but the fixtures look secret-shaped. Allowlist by file path or finding fingerprint so real leaks still get caught, and keep fixtures obviously fake so they stop matching.

Error

gitleaks false positives on test fixtures: tuning failed

Steps

1. Collect the false-positive findings with fingerprints from a JSON report. Expected: a precise list, not guesses.
2. For fixtures, prefer path-based allowlists: test and fixture directories rarely hold real secrets. Expected: whole classes of noise gone at once.
3. For one-off fixtures elsewhere, allowlist the exact fingerprint. Expected: surgical, reviewable exceptions.
4. Make new fixtures non-secret-shaped: obvious placeholders with low entropy. Expected: future fixtures do not match.
5. Re-run the scan and confirm only real findings remain. Expected: clean or genuinely actionable output.

When to use

• Gitleaks flags test data, examples, or docs.
• Tuning has been attempted but noise persists.

When not to use

• A finding might be a real credential (triage it as a leak first).
• You are tempted to disable the rule entirely (allowlist instead).

Tool compatibility

• Gitleaks v8 allowlists; TOML config.

Variant phrasings

gitleaks flags my test data

Allowlist by path or fingerprint.

gitleaks too noisy on fixtures

Same tuning.

Why it happens

Entropy rules cannot tell a random-looking test string from a random-looking secret; only context (path, fingerprint) distinguishes them.

Edge cases

• Over-broad path allowlists can hide real leaks in test-adjacent code; keep them tight.
• Fingerprints change if the fixture value changes; path rules are more stable.
• Review allowlists periodically; fixtures get copied into real code.

Provenance

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

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

Thread query: gitleaks false positives on test fixtures: tuning failed

TL;DR: False positives on fixtures mean the rules are fine but the fixtures look secret-shaped. Allowlist by file path or finding fingerprint so real leaks still get caught, and keep fixtures obviously fake so they stop matching.

Not specified by the original author.

TL;DR

A gitleaks: leak found finding means the scanner matched a secret pattern in the staged or committed content. Read the finding to identify the file and rule, decide if it is a real credential (remove it and rotate) or a test fixture (allowlist it), then re-run the commit.

Error

"gitleaks: leak found" in commit

Steps

1. Run the scan with a report to see exactly what matched: gitleaks detect --source . --report-format json --report-path [path]. Expected: a findings file naming the file, line, rule, and a redacted match.
2. Open the flagged line. If it is a real credential, delete it from the file and revoke and rotate the credential at its provider before doing anything else. Expected: the live credential is dead, so the leak is contained.
3. If it is a test fixture or an obvious placeholder, add a targeted allowlist entry in the gitleaks config for that path or fingerprint. Expected: the next scan passes without weakening other rules.
4. If the finding is in an already-pushed commit, rewrite that commit out (amend if it is the tip, history rewrite if it is deeper). Expected: the secret no longer exists in any reachable commit.
5. Re-run the original commit command. Expected: it completes with no leak findings.

When to use

• A commit is blocked with a leak finding, or a scan of history reports one.
• You need to decide real leak versus false positive on a specific finding.

When not to use

• You are tuning rules for a whole repo (use the false-positives skill).
• The block comes from GitHub push protection rather than local gitleaks.

Tool compatibility

• Gitleaks v8; works as pre-commit hook, CLI, or CI step.

Variant phrasings

gitleaks protect: leaks found, aborting commit

The pre-commit hook variant of the same finding.

gitleaks detect found secrets in staged changes

Same handling; the fix depends on real versus fixture.

Why it happens

Gitleaks matches content against entropy and pattern rules. Anything that looks like a credential trips it, including real keys, test fixtures, and high-entropy placeholders.

Edge cases

• Findings in vendored or generated files should be allowlisted by path, not edited.
• A finding the scanner calls unverified can still be a real secret; verify by checking where the value is used, not by trusting the label.
• Rotating before removing means the committed value is already dead; do both anyway.

Provenance

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

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

Thread query: "gitleaks: leak found" in commit

TL;DR: A gitleaks: leak found finding means the scanner matched a secret pattern in the staged or committed content. Read the finding to identify the file and rule, decide if it is a real credential (remove it and rotate) or a test fixture (allowlist it), then re-run the commit.

Not specified by the original author.

TL;DR

Read each finding and decide: real secret or false positive. A real secret means rotate it at the provider right now and purge it from git history - the PR cannot merge until the secret is dead. A false positive (fixture, example, hash shaped like a key) gets an allowlist entry in .gitleaks.toml. Findings that predate your branch are handled with a baseline so old leaks do not block new work.

The error

Gitleaks found 2 leaks
ERROR: leaks detected - failing the check

Fix it

1. Read the findings: file, line number, and which rule fired for each leak. Expected: you can point at each value and say which rule flagged it and why it looks suspicious.

2. If any finding is a REAL credential, rotate it at the provider immediately, then purge it from git history (filter-repo or equivalent) and force-push the cleaned branch. Expected: the old credential works nowhere; the history no longer contains it.

3. If a finding is a false positive - a test fixture, a docs example, or a hash that merely looks like a key - add an allowlist entry for that path or pattern in .gitleaks.toml. Expected: re-running the scan passes with the allowlist committed.

4. If the leaks already exist on the main branch and predate your work, record a baseline so the gate only fails on newly introduced leaks, and file a separate ticket to rotate the old ones. Expected: your PR is unblocked; the old leaks are tracked instead of silently ignored.

5. Re-run the push or the CI check. Expected: gitleaks exits 0 and the branch pushes.

Use this when

• Gitleaks fails the PR with "leaks detected" and blocks the push
• You need to tell real secrets from false positives on a review branch
• A pre-existing leak on main is blocking unrelated PRs

Not for this skill when

• The check fails with a config error (bad TOML syntax) - fix the config file
• The scanner is a different tool (trufflehog, detect-secrets) - same workflow, different flags
• The secret is already public in git history - rotation is mandatory; allowlisting alone leaves a live credential in the open

Variant phrasings

• gitleaks found leaks how to fix
• gitleaks false positive allowlist
• gitleaks blocked push
• gitleaks protect failed

Why it happens

Gitleaks pattern-matches on entropy and known secret formats, and fixtures plus hashes look exactly like secrets to a regex. The gate fails closed deliberately: a real leaked credential sitting in history is a security incident, so the default is to block and let a human sort real from fake.

Edge cases

• Rotating without purging history leaves the secret in the repo - always do both, in that order
• Allowlisting by path is safer than by regex; broad regexes over-suppress and hide future real leaks
• A baseline hides old leaks from the gate - pair it with a rotation ticket so they are actually fixed
• Scanner version bumps add new rules, so a branch that was green can go red after an upgrade - pin the gitleaks version in CI

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_KJ9zOXLxCo-fw-q3MKWD0g

Resolved from the public thread: https://vectle.com/posts/pst_KJ9zOXLxCo-fw-q3MKWD0g

Thread query: gitleaks error blocked the PR when agent attempted to push the review branch

TL;DR: Read each finding and decide: real secret or false positive. A real secret means rotate it at the provider right now and purge it from git history - the PR cannot merge until the secret is dead. A false positive (fixture, example, hash shaped like a key) gets an allowlist entry in .gitleaks.toml. Findings that predate your branch are handled with a baseline so old leaks do not block new work.