How we count
What each total on the dashboard, Projects, BOM, Findings and evidence pages counts, and why two of them can differ.
The same findings appear on many screens. Most totals use one definition, so they show the same number. Where a screen counts something else, it says so. This page lists what each total counts.
Vulnerabilities and findings
- A vulnerability is one advisory ID, such as a CVE or GHSA.
- A finding is one vulnerability on one component of a BOM. A vulnerability that affects three components (for example three versions of the same library) is three findings.
A total labelled vulnerabilities counts each ID once in its scope. A table that lists findings has one row per finding, so it can have more rows than the vulnerability total above it.
What is counted
- Current BOMs only. For each project: the newest parsed BOM of each type (SBOM, HBOM, ...) and its latest successful scan. Older versions and their scans are not counted.
- Active findings only. Findings that applicability rules filtered out (out of scope or excluded) are not counted. Screens show them separately as not applicable or filtered.
- Highest severity. A vulnerability found at different severities (on different components or in different BOMs) counts once, at its highest severity.
- VEX. Open leaves out vulnerabilities that a VEX statement marks not affected or fixed on every finding. Screens that show all active vulnerabilities say how many of them VEX resolves.
Where each number comes from
| Screen | Total | What it counts |
|---|---|---|
| Dashboard | Open findings | Open vulnerabilities across the organization, each once, plus code findings. Vulnerabilities resolved by VEX are not counted. |
| Dashboard | Findings posture | Every active vulnerability across the organization, each once, with how many VEX resolves. |
| Dashboard | Velocity: open findings (per package, per BOM) | Tracked findings: one per vulnerability per package per BOM. This is higher than the vulnerability total. |
| Dashboard, Projects, project overview, BOMs list | Per project or per BOM | The vulnerabilities in that project's current BOMs (or in that BOM), each once. The Projects list adds the project's code findings. |
| Projects | Findings card | The sum of the project totals. A vulnerability in two projects counts twice; the dashboard counts it once. |
| BOM page | Vulnerabilities | The vulnerabilities in this BOM, each once. The Vulnerabilities tab lists the findings behind them. |
| Scan page | Active findings | The findings of that scan, with the number of unique vulnerabilities in brackets. |
| Findings | Open findings | As on the dashboard. Filters narrow it. |
| Evidence bundle | summary.json, vulnerabilities.csv | vulnerabilities counts IDs; findings and the rows of vulnerabilities.csv count findings. count_definitions in summary.json describes each count. |
| Decisions | Total assertions | VEX statements, not vulnerabilities. The review queues list findings. |
A vulnerability shared by several projects counts once in each project. That is by design: each project has to deal with it.
BOMs
BOMs means the current version of each BOM: what the BOMs page lists. Every uploaded version is on a BOM's History tab, and the Projects page shows how many versions were uploaded in all.
Scans
- Success rate = succeeded scans divided by finished scans (succeeded plus failed), to one decimal. Cancelled scans are not counted. Both the dashboard and Activity count all scans, unless you filter Activity.
- Median duration. The dashboard measures from queued to finished, so it includes time spent waiting for a worker. Activity measures the run time, from started to finished, so its median is shorter.
Coverage
"N of M components could be matched to vulnerability data" counts distinct components (name and version). A part listed twice in the file counts once. Two hardware parts with the same name and version (two identical chips with their own bom-refs, or the same part name from two suppliers) count as two.
Only parts with a package URL, a CPE or a matching applicability rule can be matched, so a scan with no findings says how much it could check, with no threshold:
| Parts that could be checked | Shown |
|---|---|
| The BOM lists no components | Empty BOM |
| None | Not assessable |
| Some (A of M) | No known vulnerabilities in A of M parts |
| All | No known vulnerabilities |
| Not recorded | No known vulnerabilities (coverage not recorded) |
Scans that stored no coverage (before May 2026) count the components that have a
package URL or CPE. The evidence bundle's summary.json gives the same numbers under
coverage.
Licenses
License review on the Components page and license_issues on the dashboard and in
the API count components whose license verdict is Needs review or Not allowed (see
Inventory). Hardware parts without a license are not counted.
The evidence bundle's summary.json counts every component of the bundle once under
licenses: one count per verdict (allowed, needs_review, not_allowed,
not_applicable), by_category (components per license category) and
no_license_declared; total is the number of distinct license expressions. On the
bundle record (the evidence bundle list and its API), licenses_unknown is the number
of components in the Unknown category (no license declared, or not recognised), not a
verdict; licenses_restricted is the number whose verdict is Not allowed.
The category of an expression that mixes AND and OR follows SPDX precedence:
parentheses first, and AND binds tighter than OR. Each OR branch counts as its
most restrictive license, and the expression takes the least restrictive branch. So
MIT OR (GPL-3.0-or-later AND MIT) is permissive and LGPL-3.0-or-later AND Apache-2.0
is weak copyleft.