## 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

```text
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