Pick the unit that matches the decision. Count unique CVEs to describe exposure types, affected packages to scope work, instances to see spread, and distinct fixes to estimate effort. Most dashboards mix these silently, which is why two reports on the same estate can disagree by a large factor.
The four units
Take one flawed library used by many services.
- CVE or advisory. One record, whatever it affects. Good for "what kinds of problems do we have?"
- Package and version. One row per affected package version. Good for "what needs updating?"
- Instance. One row per place the package is found: each repo, image, service or build. Good for "how widespread is it?"
- Fix. One row per remediation action, such as one version bump that clears several advisories. Good for "how much work is this?"
The same situation can be one CVE, one package, forty instances and one fix.
What each count hides
| Unit | Inflates when | Understates when |
|---|---|---|
| CVE | Never much | One CVE touches thousands of places |
| Package | Several versions in use | Many unrelated packages share one root cause |
| Instance | A common library is everywhere | Hides that one upgrade solves all of it |
| Fix | Bundles are generous | Hides how many systems are exposed |
Instance counts are the usual cause of alarming charts. They count the same upgrade many times. Fix counts are the most useful for planning, and the least often shown.
Direct versus transitive
Another split matters: whether the vulnerable package is a direct dependency you chose or a transitive one pulled in by something else. A transitive finding may need the parent updated, or an override, so one finding can take longer than another of the same severity. If your scanner reads only direct dependencies, counts will be lower and also less complete.
Steps to make the count consistent
- Write the unit into the metric name: "open advisories", "affected package versions", "affected instances", "distinct fixes".
- Deduplicate before counting. Merge rows that share an advisory, package version and location.
- Report two units side by side for management: instances for spread, fixes for effort.
- Keep the unit fixed across periods. A switch of unit is a break in the trend line.
- When tools disagree, compare units first. The difference is often definitional.
Why the unit changes the story
Suppose leadership sees "400 critical findings" and assumes 400 engineering tasks. If those are instances of two advisories fixed by two upgrades, the real work is small and urgent. Reporting both numbers prevents panic and prevents complacency.
Matching unit to audience
- Engineers: fixes and affected packages with owners.
- Security leads: advisories and instances, split by context such as reachable or exposed.
- Executives: distinct fixes open, oldest open age and trend.
Safeguard offers SBOM and dependency scanning, reachability analysis and policy gates. You can run a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how one dependency appears across the inventory and think about which unit you would count.
Quick check
Which unit should a board report use?
Show distinct open fixes and the oldest open age, with instances as context.
Why do two scanners report different totals?
They often count different units or read different dependency depths. Align the unit before comparing.
Last reviewed: 19 October 2026.
