Record a baseline before you trial a tool: backlog size and age, time to fix by severity, share of assets covered, and share of findings with a named owner. Compare the same numbers after. Without a baseline, any improvement is an anecdote and any regression is an argument.
Why baseline first
Teams buy a tool, feel busier, and cannot say whether things improved. Measure for four weeks before the trial. Even a rough baseline from the spreadsheet beats none.
Metrics worth tracking
Backlog size and median age of open findings. Median and ninetieth percentile time to fix, split by severity or by priority class. Coverage, meaning assets scanned divided by assets known. Ownership, meaning findings with an owner divided by all findings. Reopen rate, meaning fixes that reappear.
Metrics that mislead
Raw finding count rises when a better tool looks harder, which looks like failure and is the opposite. Average time to fix hides a long tail. Count of critical findings depends on a scoring scheme that may change between tools. Prefer ratios and medians.
Separate detection from workflow
A tool can improve detection, workflow or both. Track them apart. Detection shows in coverage and in seeded test results. Workflow shows in time to fix and ownership.
Set targets as ranges
Agree before the trial what counts as success: for example, ownership above a level you choose, or a shorter ninetieth percentile fix time. Write the targets down, because moving goalposts after the fact is common.
Reporting to leadership
Show the baseline, the trial result and what was held constant. Note limits: a two week trial cannot show long term fix times, so say which metrics are indicative only.
One more habit helps: freeze the definitions. Write down exactly how you count an asset, a finding and a fix, and keep those definitions the same through the trial. A tool that merges duplicates will report fewer findings than one that does not, so compare on definitions you control, and note any difference in how each tool counts.
Where Safeguard fits
Safeguard covers SBOM and dependency scanning, reachability analysis, policies and gates, and fix pull requests that stay off until you turn them on. You can try a free scan on a repository before you commit to anything.
Try it yourself
Look at the summary figures on the findings view and decide which of them you would track weekly.
Click through it at your own pace, or open it full screen.
Quick check
How long should the baseline be?
Four weeks gives a usable picture for most teams.
Should I count total findings?
Track it, but do not use it as a success measure.
Last reviewed: 19 October 2026.
