gitleaks --baseline-path: Ignore Known Findings
gitleaks --baseline-path takes a previous JSON report and only fails on findings that are not already in it.
Adopting gitleaks on an old repo full of historical leaks is painful if every run fails. A baseline records the known set so the gate triggers only on new secrets.
What it does
You first generate a report with --report-path, then pass that file as --baseline-path on later runs. gitleaks subtracts the baselined findings (matched by fingerprint) and exits non-zero only on genuinely new leaks.
Common usage
# 1. capture current findings as the baseline
gitleaks detect --source . --report-path gitleaks-baseline.json
# 2. later runs only fail on NEW leaks
gitleaks detect --source . \
--baseline-path gitleaks-baseline.json --verboseOptions
| Flag | What it does |
|---|---|
| --report-path <file> | Write the JSON report (used to seed a baseline) |
| --baseline-path <file> | Ignore findings already present in this report |
| --report-format json | Baselines must be JSON; keep the default format |
| -v, --verbose | Show the new findings that survive the baseline |
In CI
Commit the baseline JSON and refresh it deliberately after you have rotated or removed the old secrets, not as a way to permanently bury them. The baseline matches on a fingerprint of file+commit+rule, so rebasing history can invalidate entries and surface old findings as new.
Common errors in CI
"could not open baseline file" means the path is wrong or the file was not committed/restored in the job. Old findings reappearing after a rebase is expected: the commit SHA in the fingerprint changed, so regenerate the baseline. The baseline must be --report-format json; a SARIF baseline is not accepted.