Record a baseline of everything the scanner finds today, fail builds only on secrets that are not in that baseline, and clear the old findings in a separate, time boxed effort. This lets you stop new leaks on day one without freezing every pull request behind years of history.
Why old repos break the rollout
Run a scanner over a repository that is ten years old and you will often get hundreds of findings. Some are real keys, many are test fixtures, hashes and example strings. If the first thing a developer sees is a red build they did not cause, the tool gets switched off within a week.
The fix is to separate two jobs. Job one is stopping new secrets. Job two is cleaning up the past. They have different owners, different deadlines and different urgency.
The baseline approach
A baseline is a file that records the findings that already exist. Some open source scanners support this directly. The detect-secrets project, for example, writes a baseline file from a first scan, and later scans against that file report only secrets that are new. Re-running the scan updates the file, adding new items and dropping ones that no longer exist.
The steps:
- Run a full scan on the default branch and save the output as the baseline.
- Commit the baseline file so every clone shares the same starting point.
- Configure the pre-commit hook and the CI job to compare against the baseline.
- Fail on any finding that is not in the baseline.
- Start the cleanup track.
Step 4 is the one that matters. From that point the count of known bad items can only go down.
Triage the baseline in three buckets
Do not treat every baseline entry equally. Sort them.
| Bucket | What it is | Action |
|---|---|---|
| Live credential | A real key or password that still works | Revoke and rotate now, then mark resolved |
| Dead credential | Real once, already revoked or expired | Confirm with the provider, then mark resolved |
| Not a secret | Test data, hash, example value | Label as false positive with a reason |
Auditing tools help here. The detect-secrets audit command, for instance, lets a reviewer label each baseline item as a real secret or a false positive, and those labels feed back into tuning.
Work the live bucket first. A live key in an old commit is exactly as dangerous as one committed this morning, because history is readable by anyone with repository access. GitHub's guidance is blunt about it: treat any leaked secret as compromised, and remember that deleting it from the code does not stop it being used.
Keep the baseline honest
A baseline can become a hiding place. Put guardrails around it.
- Review changes to the baseline file in pull requests, like any security control.
- Do not let people add new items to silence a failure without a stated reason.
- Report the baseline size every month so the trend is visible.
- Set a target date for an empty baseline, even if it is a few quarters away.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a gate blocks only what a pull request introduces, which is the same principle a baseline gives you for secrets.
Quick check
Should I rewrite git history to remove old secrets first?
Not first. Revoke and rotate the live ones, because that ends the risk. Rewriting history is disruptive and can be scheduled later if you still want it. See what survives a history rewrite.
Is a baseline the same as ignoring findings?
No, if you track it. A baseline is a dated list of debts with a plan to pay them. Ignoring is silent and permanent.
Safeguard can run policy gates on pull requests and scan repositories for exposed credentials; you can try a free scan on a repository to see what a first pass looks like.
Sources
Last reviewed: 19 October 2026.
