A vulnerability count can measure three different things: unique CVE or advisory IDs, findings (one ID in one component), or instances (one finding on one asset). The same environment can produce very different totals under each. Pick one unit, write it on the chart, and never compare numbers that use different units.
Three units, one environment
Imagine one library with a single known advisory, used in four services, and each service runs on three hosts. Under the first unit you have one vulnerability. Under the second you have four findings, one per service. Under the third you have twelve instances. Nothing about the risk changed between those three sentences. Only the counting rule did.
| Unit | What it counts | Good for | Misleading when |
|---|---|---|---|
| Unique ID | Distinct CVE or advisory identifiers | Tracking exposure to a named issue | Judging workload, because one ID can need many fixes |
| Finding | One ID in one component or repository | Planning fix work, since one fix usually closes one finding | Comparing teams of different size |
| Instance | One finding on one asset or deployment | Measuring blast radius and rollout progress | Reporting effort, because a single patch can clear many instances |
Why this matters for trends
If a report mixes units across months, a line can fall without any fixing. A team that moves from instance counts to finding counts will see a sudden drop that looks like a win. The reverse switch looks like a disaster. Whenever the unit changes, annotate the chart and restate the earlier months under the new rule if the data allows it.
How to choose
Use the unit that matches the decision the reader will make.
- Leadership asking "how exposed are we to this named issue" wants unique IDs, plus the number of affected assets next to it.
- Engineering managers planning a sprint want findings, grouped by the repository that owns the fix.
- Operations teams rolling out a patch want instances, since each one is a deployment to update.
State the unit in the chart title, for example "Open findings by severity", not "Open vulnerabilities". The extra word costs nothing and prevents most arguments.
Aliases make the ID count shaky
Even the unique ID unit has a catch. The OSV schema defines two entries as aliases when they affect a given software component the same way, and notes that one patch would fix both. A CVE and a distribution or ecosystem advisory can therefore describe the same problem under different IDs. If your pipeline counts each ID separately, one issue is counted twice. Normalise on aliases before you count, and keep the original IDs in the record so that people can still search for them.
A short test for your own dashboard
Pick any single number on the dashboard and ask three questions. Which unit is it? Can I list the rows behind it? If I click through, does the list length match the number? If the answer to the third question is no, the display and the data use different counting rules, and that is the first thing to fix.
Safeguard does this kind of counting in one place: SBOM and dependency scanning, asset discovery and reachability analysis feed the same inventory, so each number can be traced back to its source. Findings link back to the component and asset they came from, which makes the unit explicit. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Open the demo and follow one finding from detection to resolution, noting which number on screen changes and which stays put.
Click through it at your own pace, or open it full screen.
Quick check
Is a finding the same as a vulnerability?
Not always. A vulnerability is the issue itself, usually identified by an advisory or CVE ID. A finding is that issue observed in one specific component or repository. One vulnerability can produce many findings.
Which unit should I show a board?
Show unique IDs for named, high-profile issues with the count of affected assets beside them, and show findings for general trend lines. Label the unit either way.
Sources
Last reviewed: 19 October 2026.
