## TL;DR
A leaks-found failure is a triage problem, not automatically a revocation problem. Read the finding's file, line, and rule, decide whether it is a real secret, a test fixture, or a false positive, then revoke, allowlist, or fix the pattern in that order.

```text
leaks found: [N]
```

## Steps

1. Get the full finding with file, line, and matched rule:
```bash
gitleaks detect --source . --verbose --report-format json --report-path [REPORT_PATH]
```
Expected: a JSON report naming each finding's file, line number, rule ID, and a redacted secret preview.

2. Classify each finding before touching anything:
```bash
# for each finding, open the file at the reported line and ask:
# is this a real credential, a test fixture, or a false positive?
```
Expected: every finding lands in one of the three buckets. Real secrets go in bucket one; everything else must not be revoked.

3. For a real secret, revoke it at the source first, then remove it from history:
```bash
# revoke or rotate the credential in its provider console, then
# remove it from git history with filter-repo or BFG, then force-push
```
Expected: the old value is dead at the provider, so even the history copy is harmless, and the scanner passes on the cleaned tree.

4. For test fixtures and false positives, add a targeted allowlist entry:
```toml
# in .gitleaks.toml
[[rules.allowlist]]
regexes = ['''[FALSE_POSITIVE_PATTERN]''']
```
Expected: rerunning gitleaks no longer flags the fixture, while the rule still catches real secrets elsewhere.

5. Rerun the scanner on the exact CI scope to confirm green:
```bash
gitleaks detect --source . --config [CONFIG_PATH]
```
Expected: exit code 0 and no findings, matching what CI will see.

## When to use
- gitleaks fails CI with leaks found and you need to triage
- A new rule or config version starts flagging previously clean code
- You need to distinguish real leaks from fixtures without blanket-disabling rules

## When not to use
- The failure is a gitleaks crash or config parse error; that is tooling, not findings
- Another scanner (trufflehog, git-secrets) reports; the triage shape is similar but the config differs
- You want to prevent leaks; that is pre-commit hooks, a different setup task

## Why it happens
Gitleaks matches entropy and patterns, so high-entropy test tokens, example keys from docs, and hashes in fixtures all look like secrets to it. Real leaks usually come from a credential pasted during debugging and committed accidentally. The scanner cannot tell intent, so a human classifies each finding.

## Edge cases
- A finding in git history but not in the working tree still fails scans that cover history; clean the history or scope the scan
- Rotating without removing from history leaves the secret in the repo for anyone who clones it
- Blanket allowlisting a whole rule to silence one fixture blinds you to real leaks of that type; scope the allowlist to the path or line
- Fork PRs from outside contributors can introduce findings the base branch never had; run the scanner on the merge result, not just the base

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IHI-Qbs8-_bfjuAQqT2nOA