Vulnerabilities
What counts as one vulnerability
Navigator counts vulnerabilities the same way the wider vulnerability-management industry does: one instance is one CVE (or pre-CVE weakness) on one device. If the same CVE reaches a device through two different affected software installs — say, both Chrome and Zoom carry the same underlying flaw — that’s two instances, not one, because they’re two independent things that each need remediating. This is the same definition Tenable (“a single instance of a vulnerability appearing on an asset”) and Rapid7 InsightVM (“an asset can be vulnerable to the same vulnerability in multiple ways”) use in their own products — Navigator isn’t inventing a new standard, just applying the one already common across the field.
Every number Navigator reports as “vulnerabilities” — the Dashboard’s KPI card, the exposure Sankey, the Vulnerabilities page’s own total — counts by this same instance definition, so they always agree with each other.
The list page groups rows for readability, not for counting
The table itself shows one row per unique vulnerability (grouped by name and CVE) rather than one row per raw instance, because scrolling past 50 nearly-identical rows for one CVE affecting 50 devices isn’t useful. Each row carries its own affected-device count in the Devices column, linking directly to exactly which of your devices are affected. The page’s own total, shown next to the table, is the real instance count — the sum of every row’s own count — so it stays consistent with every other “vulnerabilities” number in Navigator even though fewer rows are actually on screen.
Need to compare how two different sources reported the exact same instance? Each grouped row links out to its raw per-source records for that kind of side-by-side comparison.
Enrichment
Every vulnerability is automatically enriched with data from public feeds, shown inline without needing your own lookup:
- CVSS score and vector, with the reporting source noted
- EPSS: FIRST.org’s exploitation-probability score and percentile
- KEV: flagged when a CVE is on CISA’s official Known Exploited Vulnerabilities list, or VulnCheck’s broader tracked-exploitation list (shown as a flame icon; hover to see which list)
- Description, CWE, and SSVC decision points, where available
This enrichment runs against public data (VulnCheck Community, FIRST EPSS, CISA KEV). It never sends your data anywhere; it only adds public reference information on top of what your own connectors reported.
Filtering and search
Filter by Severity or Source in the facet rail, or use the KEV filter to see only actively-exploited vulnerabilities. The Devices column links directly to a pre-filtered Devices view showing exactly which of your devices are affected.
Known gap: not every field is populated by every source
Some fields depend on what a specific connector reports. For example, cvss_score before enrichment is only set by connectors that report a numeric score natively, and remediation-SLA tracking depends on a “first found” timestamp not every connector’s API exposes. Where a field genuinely isn’t available yet, it’s shown as a dash rather than a fabricated value.
Similarly, how finely Navigator can tell two instances of the same CVE on one device apart depends on what that connector’s own tool reports — a scanner that reports which specific software install is affected lets Navigator count that distinction correctly; a tool that only reports “this device has this CVE,” with no further detail, is counted as a single instance. This is a real capability difference between security tools, not a Navigator limitation — the fix, if it matters to you, is the same one you’d need for any vulnerability-management platform: a tool with finer per-finding reporting.