Prioritisation
Exploitation first, severity second
A fleet of thirty hosts can easily produce several hundred High and Critical findings. Sorted by CVSS alone, nothing tells you which few matter this week. CveDeck ranks every finding by three signals, in a fixed order.
KEV, then EPSS, then CVSS
CVSS says how bad a vulnerability would be if exploited. KEV says whether it is being exploited right now. EPSS says how likely that is to start. Both the fleet list and the findings table use this order by default.
-
1CISA KEV
Is it being exploited right now? The US Cybersecurity and Infrastructure Security Agency's catalog lists CVEs with confirmed exploitation in the wild. Findings on it come first, shown with the federal remediation due date.
-
2FIRST EPSS
How likely is exploitation to start? The Exploit Prediction Scoring System gives each published CVE a modelled probability of exploitation in the next 30 days. CveDeck shows the score and its percentile.
-
3CVSS
How bad would it be if exploited? The CVSS score comes after KEV and EPSS in the sort order. It still counts, but it no longer buries an exploited Medium under a Critical nobody has touched.
In practice, a CVSS 6.5 that CISA lists as actively exploited outranks a CVSS 9.8 that nobody has touched, because what is happening beats what could happen.
Not every advisory carries a score
A severity and a score are separate facts, and either can be missing. An advisory can publish a band with no number, a number with no band, or neither. A finding with neither is Unscored — its own severity, counted alongside the other four.
It used to be scored 5.0 and reported as Medium, which was a measurement-shaped answer to a question the advisory never answered, and indistinguishable from a record genuinely scored 5.0.
- Unscored ranks below Critical and above High. An unmeasured finding could be either, so filing it with the least severe would be the same quiet all-clear that the invented 5.0 was.
- Within a band, a published band with no number leads. A qualitative "High" could be an 8.9, so it sorts ahead of the measured Highs rather than falling to the bottom of them.
- Unscored is painted a neutral slate, off the severity ramp entirely. The ramp is one warm hue, red is reserved for exploitation, and a fifth depth of amber would state a severity nobody published.
Why the percentile matters as much as the score
EPSS scores are heavily skewed. The overwhelming majority of CVEs score below 0.01, so an absolute score that looks negligible can still rank above most of the corpus. A rank reads correctly where a raw probability misleads, so CveDeck displays both.
Three exploitation states, never two
"Not on the list" and "never checked" look identical in most tools. They are not the same answer, so CveDeck keeps them apart at every layer, from the database to the screen.
| State | Meaning | Shown as |
|---|---|---|
| Listed | On CISA's Known Exploited Vulnerabilities catalog. | Exploited |
| Not listed | Checked against a usable catalog, and genuinely absent. | Not on KEV |
| Unknown | Not checked: no usable catalog existed when the finding was recorded. | A muted dash, never a zero |
A zero is an assertion; a dash is the honest absence of one. When no usable feed is loaded, the fleet's "Actively exploited" card shows a dash and "no exploit data loaded", not a count. See honest reporting for the same rule applied to scan results.
Counting these three states up into a summary needs a fourth, because a host can be partly checked: what a host's headline is entitled to claim.
Where the data comes from
The two kinds of data are fetched differently, on purpose.
- Package advisories are queried during a scan. Package-level matching uses OSV.dev, which carries distribution trackers such as Ubuntu's and Debian's. OS-level matching against NIST NVD is available but off by default, because NVD's rate limits make an unkeyed fleet scan slow.
- Exploitation data is downloaded whole and cached. CISA KEV and FIRST EPSS each publish a complete file daily. CveDeck downloads them once and joins them offline, so enrichment adds no network dependency to a scan.
When a refresh fails
- A failed refresh never empties a good cache. Yesterday's answer beats no answer, and an empty catalog returned as a success is treated as a failure.
- Staleness is reported, not hidden. A feed's last-refreshed time only moves on success, and the dashboard shows a banner when a feed is stale or unusable.
- A refresh that changes nothing does nothing. The published file is compared against the one already cached, and an identical one short-circuits rather than being reapplied.
- An emptied catalog is not a catalog. A feed that returns far fewer records than the cache it would replace is refused as unusable, so an upstream mistake can't quietly clear every exploitation signal on your fleet.
- Refreshes happen on their own, every 24 hours. Set
CVEDECK_FEED_REFRESH_HOURS=0to switch that off and drive it from your own scheduler instead — but run one or the other, not both. How to schedule it. - New intel applies to the findings you already have. A refresh reapplies to stored findings, so a CVE added to KEV overnight is marked on your fleet in the morning without re-scanning. An unusable feed is never applied, so an outage can't clear a signal you already had.
CveDeck isn't affiliated with OSV.dev, NVD, CISA or FIRST. On this site, red marks exploitation and nothing else.