
How Should I Prioritize Software Vulnerabilities? | Blog | Endor Labs
Endor Labs blog post comparing five approaches to prioritizing software vulnerabilities: CVSS scoring, CISA's KEV catalog, Carnegie Mellon's SSVC decision tree, FIRST's EPSS exploit-prediction model, and call-graph-based reachability analysis. It cites concrete data (e.g., EPSS v3 threshold of 0.088 catches ~82% of exploited CVEs while requiring remediation of only 7.3% of known CVEs, versus patching most CVSS high/critical issues) and walks through each method's limitations, using examples like CVE-2017-0144 (EternalBlue/NotPetya) and CVE-2004-1464.
What it is
An Endor Labs blog post arguing that common vulnerability-prioritization methods are individually inadequate. The fetched text covers two of the five promised methods in depth: CVSS (Common Vulnerability Scoring System, maintained by FIRST) and CISA's Known Exploited Vulnerabilities (KEV) catalog. The remaining three named in the URL (EPSS, SSVC, reachability/VEX) are not present in the fetched text.
How it works
The piece is a critique, not a technique. Its actionable core is a set of specific traps:
- The 7.0 threshold is broken. ~58% of CVSS-rated CVEs in the NVD are "high" or "critical," so the common practice of remediating everything at or above 7.0 fails to prioritize — most of the backlog exceeds it. Roughly 200,000 CVEs carry NVD CVSS scores.
- CVSS scale misrepresents risk. The ~1–10 range implies the worst vuln is only ~10× the least severe, but real impact follows a power-law: CVE-2017-0144 (used by NotPetya) caused ~$10 billion in damage while most CVEs cause zero loss.
- Qualitative bands don't aggregate. You cannot say whether 10 "critical" issues are worse than 100 "high" ones; the numbers are just relabeled qualitative inputs.
- Severity ≠ risk. CVSS states this (since 2019) yet includes exploitability, so practitioners still misuse it as a risk metric. Version 4.0 (public preview at publication) adds granularity but does not fix the core critiques.
- KEV is a historical record, not a live feed. Inclusion requires a CVE ID, reliable evidence of past exploitation in the wild, and a clear remediation. A CVE stays listed even if exploitation stopped or was neutralized by compensating controls (firewall rules, etc.). Output is essentially binary, and data sources are described vaguely ("security vendors, researchers, and partners").
What to do
Nothing operational — no commands, patches, or configuration. The takeaway for an engineer: do not treat KEV membership as evidence of current active exploitation, and do not treat CVSS ≥ 7.0 as a meaningful cut line. Use both as inputs alongside other signals, not as standalone gates.
Caveats
The fetched text is truncated mid-sentence within the KEV section and never reaches EPSS, SSVC, reachability, or VEX — so despite the URL and title, this document reflects only the CVSS and KEV portions. It is a vendor post whose implicit conclusion is that better prioritization requires reachability analysis (Endor Labs' product area).
CVEs named here
- CVE-2017-0144
- CVE-2004-1464
Techniques named here
- Reachability analysis via call graphs
- EPSS threshold-based remediation prioritization
- CVSS threshold-based remediation
- SSVC decision-tree based vulnerability triage
Threat actors named here
- Petya ransomware
Related in AppSec
Flowise MCP Security Bypass Enables RCE
Inside an Oracle Database SQL Injection Attack | Huntress
OASIS
