Test whether the tool can baseline an existing codebase, so only new findings block pull requests while the old ones are tracked separately. Ask it to do that on a legacy repository during evaluation. Without a baseline, the first scan buries developers and the tool gets switched off within weeks.
The first scan problem
Run any static analysis tool on a ten year old application and the count will be large. Most teams react in one of three ways: ignore the number, try to fix everything, or turn the tool down until it is quiet. All three lose.
A better target is simple. Stop adding new problems now, and burn down old ones on a schedule you can defend. That needs tool support, so check for it before you buy.
What baselining means
A baseline is a snapshot of existing results that you accept for now. Later scans compare against it, and only results not in the snapshot are treated as new. The SARIF standard has a field for this idea, called baselineState, and a way to give results stable identifiers so they can be tracked across runs.
The detail that matters is how the tool matches an old finding to a new scan. If it matches on file path and line number, an unrelated edit above the finding makes it look new. Ask how matching works and what happens when a file is renamed or a function moves.
Tests to run in the evaluation
Pick one repository with a long history. Then:
- Scan it and record the total.
- Create the baseline. Note whether it is a one click action or a manual export.
- Add a harmless comment near the top of a file with findings. Rescan. Count how many old findings reappear as new.
- Rename a file that has findings. Rescan again.
- Add one real flaw in a new branch and confirm the pull request check flags only that one.
If three or four old findings come back as new after a comment edit, the matching is fragile. On a team making many changes a day, that fragility becomes constant noise.
Burning the backlog down
Baselining is a pause, not an answer. Ask the vendor to show how you can:
- Group old findings by rule, so one fix pattern clears many results.
- Assign owners by directory or team.
- Set an expiry on accepted risk, so a dismissal comes back for review.
- Report the baseline size over time, so leadership can see it shrinking.
A reasonable plan is to fix classes of issues rather than individual ones. If a single input handling helper is the root cause of dozens of results, one change retires them all. Triage by that kind of cluster before you triage by severity.
When a baseline is the wrong answer
Do not baseline findings that look like hard exposure, such as hardcoded credentials or injection in an internet facing handler. Triage those first, and baseline the rest. A baseline that includes a live secret is a cover up.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a gate can judge only what a pull request changes.
Quick check
Is a baseline the same as ignoring old findings?
No. Ignoring leaves them invisible. A baseline keeps them tracked, owned and reportable while you stop new ones from landing.
How often should the baseline be reviewed?
Set a date when you create it, for example quarterly, and review the size and the accepted risk expiries at that point.
Safeguard's policies and gates can evaluate pull requests, and its SBOM and dependency scanning is generally available with a free check at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
