Exploitability vs. severity: which one should drive fix order?

Two different questions, not two names for the same thing

Audience: a security engineer, AppSec lead, or eng manager staring at a backlog of findings sorted by severity and wondering why it never gets shorter. This page is not legal advice. It does not score, rank, or triage any specific finding in YOUR environment, and it does not patch anything. A named person on your team still decides what gets fixed first.

CVSS (Common Vulnerability Scoring System, maintained by FIRST) answers: if this flaw were exploited, how bad would it be, and how hard is it to reach? EPSS (Exploit Prediction Scoring System, also maintained by FIRST) answers: what is the probability someone will actually exploit this in the next 30 days? CISA's KEV catalog answers a narrower, harder question: has this specific CVE already been observed under active exploitation? SSVC answers a fourth question: given severity, exploitation status, and a few other decision points, what should a defender do next — track it, watch it, or act now? None of the four is a substitute for the others, and none of them is a determination that YOUR asset is affected.

• The CVE/CWE/CVSS explainer on this site is the concept-definitions page. The KEV explainer on this site is the confirmed-exploitation page. The prioritize-vulnerabilities guide on this site is the combined-signal ranking page.
• The vulnerability management pillar on this site introduces the discover-assess-prioritize-remediate-verify lifecycle this page's distinction sits inside. It is not published yet; naming it here is not a link.

The 2x2: severity x exploitability, with quadrant actions

This grid is a starting heuristic, not a scoring formula and not a mandate. 'High severity' means a CVSS v4.0 base score generally read as High or Critical (7.0 and above). 'High exploitability' means the CVE is on the CISA KEV catalog, or carries a materially elevated EPSS score relative to the rest of an organization's backlog. Neither axis is binary in reality — this table forces a binary split for legibility. It does not replace a documented risk-based prioritization process. Not legal advice.

• This grid does not decide whether a given asset is internet-facing, whether the vulnerable code path is reachable, or whether compensating controls already reduce risk. Those facts move a finding across the grid and are yours to establish.
• EPSS and KEV both change daily. A quadrant placement made at triage time is a snapshot; recomputing it before a release or an audit is a better practice than freezing it.

EPSS: current model, and what the score actually means

EPSS is a data-driven machine-learning model, maintained by FIRST, that publishes a daily score between 0 and 1 for essentially every published CVE. The score is an estimate of the probability that exploitation activity for that CVE will be observed in the wild within the next 30 days — not a severity rating and not a guarantee about any individual CVE. A score of 0.05 means that, among many vulnerabilities scored near 0.05, roughly 5 in 100 are expected to show observed exploitation activity in that window.

As of last verification (10 September 2026), the current model is EPSS v5, which began publishing 2026-06-15. It replaced EPSS v4 (began publishing 2025-03-17), which replaced v3 (2023-03-07), v2 (2022-02-04), and the original v1 (scores from 2021-04-14). That version history is the point of this section: the model version, feature set, and calibration change on a cadence FIRST controls, and each new version can shift scores for the same CVE without any change to the vulnerability itself. That is scoring-scheme detail — check it before quoting a specific version number in a report.

The best-practice guidance is more stable across those version changes: treat EPSS as a calibrated probability (not a percentile of severity), recompute rather than cache scores for anything long-lived like a risk register, and use it to rank the mass of findings KEV has not (yet) confirmed — EPSS fills exactly the gap a lagging indicator like KEV leaves open. This page does not run EPSS against YOUR CVE inventory.

CVSS v4.0: severity, and only severity, by default

CVSS (Common Vulnerability Scoring System), maintained by FIRST, is currently at version 4.0 (released 1 November 2023 and, as of last verification, still the current version). A CVSS v4.0 Base score ranges 0.0 to 10.0 and is calculated from mandatory Base metrics that describe the vulnerability's intrinsic, environment-independent characteristics: how it is reached, what privileges or interaction it needs, and what it compromises. Severity bands: None (0.0), Low (0.1-3.9), Medium (4.0-6.9), High (7.0-8.9), Critical (9.0-10.0).

The Base score alone says nothing about whether anyone is exploiting the flaw. CVSS v4.0 does add an optional Threat metric group (Exploit Maturity) that can be layered on top of the Base score to produce a CVSS-BT (Base + Threat) score reflecting current exploit intelligence — but that is a distinct, optional calculation from the plain Base score most scanners report by default, and most vendor-published CVSS numbers are Base-only. Treating a Base-only 9.8 as inherently more urgent than a Base-only 7.5 that is on KEV inverts the actual risk in most estates. This page does not calculate or amend any CVSS score for YOU.

CISA KEV: confirmed exploitation, and its blind spot

The CISA Known Exploited Vulnerabilities (KEV) catalog lists specific CVE IDs with reliable evidence of active exploitation in the wild. Presence on KEV is one of the strongest fix-first signals available, and it is openly published at no cost. Its blind spot is structural: a CVE is added only after exploitation has already been observed and verified, so it is a lagging indicator by design. A vulnerability under active exploitation this week may simply not be listed yet. Absence from KEV is not evidence of safety; it is evidence that CISA has not yet confirmed exploitation.

The what-is-KEV guide on this site covers the catalog's inclusion criteria and how remediation-due-date obligations attach to it in more depth. This page does not check whether any specific CVE is currently on the catalog.

CISA/FIRST SSVC: a decision methodology, not one more score

Stakeholder-Specific Vulnerability Categorization (SSVC), developed by CERT/CC and used by CISA in its own vulnerability response, is structurally different from CVSS, EPSS, and KEV: it is not a single numeric score but a decision-tree methodology. A user walks a small set of decision points — commonly including exploitation status, exposure, automatability, and technical impact (partial vs. total control) — to a small set of decision outcomes (commonly labeled Track, Track*, Attend, or Act in CISA's public materials). CISA's own remediation-timeline directive (BOD 26-04, covered on the remediation-timeframes guide on this site) states that its Table 1 timelines are informed by SSVC's methodology, using variables including asset exposure, KEV status, exploit automation, and technical impact.

SSVC is a methodology other organizations can adapt to their own decision points and outcomes; it is not, by itself, a CVSS or EPSS replacement, and CISA's federal-agency use of it is not automatically binding on a private organization adopting the same framework voluntarily. This page does not run YOUR asset through an SSVC decision tree.

Legal requirement vs framework guidance vs best practice

Do not treat a FIRST specification or a CISA catalog as a law that binds every organization the way it binds US federal civilian agencies. Last verified 10 September 2026. Not legal advice.

What to do now

This page does not build YOUR prioritization queue. The list below is a starting checklist to walk with the engineer or security lead who owns triage.

• Stop sorting the backlog by CVSS Base score alone. Pull KEV status and an EPSS score for each open finding before deciding what is actually urgent — the prioritize-vulnerabilities guide on this site covers combining all three signals into one order.
• Confirm which EPSS model version your tooling reports against; a dashboard still citing v3 or v4 methodology detail alongside a v5-era score is describing the wrong model, even though the 0-1 probability meaning has not changed.
• Do not use CVSS v4.0's optional Threat (Exploit Maturity) metric interchangeably with a plain Base score in a report; state which one a given number is.
• If a finding is on KEV, treat it as fix-first regardless of its CVSS Base score, and check the remediation-timeframes guide on this site for which clock, if any, applies to your organization.
• Recompute EPSS and re-check KEV before a release gate or an audit rather than reusing numbers from the last triage session.

Where this shows up in ShipReady Metrics

Signed-in app → Security → Findings surfaces CVSS, EPSS, and KEV status together on each finding, alongside first-party and dependency scan results, so severity and exploitability sit next to each other rather than in separate tools. That surface does not decide which finding is urgent for YOUR environment, does not patch anything, and does not run an SSVC decision tree. A named human on the team still triages and closes each finding.

This page does not document a public product demo path.

Primary sources (last verified 10 September 2026)

FIRST's CVSS v4.0 specification and FAQ (current version as of last verification), FIRST's EPSS model pages, FAQ, and 'Get the Data' documentation (current model EPSS v5, publishing since 2026-06-15), CISA's Known Exploited Vulnerabilities catalog and criteria pages, and CISA's published guidance referencing Stakeholder-Specific Vulnerability Categorization (SSVC), co-developed with CERT/CC. These are not a complete list of every scoring or prioritization scheme in use. Not legal advice.

The CVE/CWE/CVSS explainer, the KEV explainer, the prioritize-vulnerabilities guide, and the remediation-timeframes guide on this site are the closest related pages. The vulnerability management pillar is not published yet; naming it is not a link.

Frequently asked questions