Skip to content

Back to the catalog

How Should I Prioritize Software Vulnerabilities? | Blog | Endor Labs
endorlabs.comarticle

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.

TL;DR A technical breakdown of CVSS, KEV, SSVC, EPSS, and reachability analysis for prioritizing which open-source vulnerabilities to actually fix first.
Document

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

Technologies named here

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