Read the first results screen by questioning five things: what the headline total counts, how many unique packages sit behind it, how severity is split, how many findings have a fix, and what the scan covered. Big numbers look dramatic, but each can mean something different.
Start with definitions
Before you react to any number, ask what the unit is. A scanner can count:
- Findings, meaning one vulnerability on one package in one place.
- Vulnerabilities, meaning unique advisories, regardless of how many places they appear.
- Vulnerable packages, meaning unique components with at least one advisory.
One outdated library used in twelve services can produce twelve findings, one vulnerability, and one vulnerable package. The same repository can honestly be described by any of the three. Ask which one the headline is.
The five numbers
| Number | Question to ask | Why it matters |
|---|---|---|
| Total findings | What is being counted? | A large total can come from duplicates |
| Unique packages | How many distinct components? | This is closer to the real work |
| Severity mix | Which score, and from where? | Scores differ between sources |
| Fixable share | Fix available, or fix tested? | A version bump exists is not the same as it builds |
| Scan scope | Which files and branches? | A small scope gives a small number |
The CVSS standard defines a way to turn a vulnerability's characteristics into a numerical score, which is then mapped to low, medium, high and critical. It describes severity. It does not say whether the flaw is being exploited or whether your code reaches it, so the severity mix is a starting point, not a ranking of risk (see FIRST's CVSS page in Sources).
Questions that expose the real picture
- Remove duplicates. Ask to group by package. See how the total shrinks.
- Filter to one severity. Pick the highest and open three. Are they relevant to your repo?
- Filter by fix. Show only those with a fix and ask how the fix was chosen.
- Check the date. Ask when the advisory data was last updated.
- Check scope. Ask which branch was scanned and whether tests, build tooling and dev dependencies were included.
Dev dependencies are a common source of surprise. A finding in a test-only tool is real, but it rarely sits on the same level as a flaw in a production library.
A common mistake
Buyers often compare the headline total across two tools. That comparison is nearly meaningless unless both counted the same unit, scanned the same branch, and applied the same filters. If you must compare, export both and count unique package and advisory pairs yourself.
Where Safeguard fits
Safeguard shows findings alongside reachability analysis, so you can see which vulnerable packages your code actually calls. Try the demo below, then run your own repository through the free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
On the results view, find the headline number and ask what it counts, then look for how severity and fix status are shown.
Quick check
Is a bigger number a better scan?
No. A big number can mean wide coverage or heavy duplication. Always ask for unique packages and unique advisories.
Does a critical label mean I must fix it today?
Not automatically. Critical describes severity under CVSS. Check exploitation evidence and whether your code reaches the vulnerable function before setting urgency.
Sources
Last reviewed: 19 October 2026.
