Skip to content
WorakornKoonawootrittriron
Back to blog
Network security

CVSS measures severity, not risk: patch priority with EPSS and KEV

CVSS-B rates severity, EPSS the chance of exploitation within 30 days, KEV confirmed attacks. Six myths, BOD 26-04, and a triage order for firewalls and VPNs.

Advanced10 min read

On this page
  1. Myth 1: "A CVSS base score of 9.8 means high risk"
  2. Myth 2: "The NVD score is the official score"
  3. Myth 3: "EPSS is just another severity score"
  4. Myth 4: "If it's not in KEV, it's not being exploited"
  5. Myth 5: "BOD 22-01 says two weeks, so we have two weeks"
  6. Myth 6: "We need one number to sort by"
  7. Putting it together: a triage order for network devices
  8. Honest caveats

Every month the scanner report lands, and every month it has the same shape: a long list of findings, and a worrying number of them marked critical. If everything is critical, nothing is. The team either works the list top to bottom by score or freezes.

The way out is not a better spreadsheet. It's knowing what each number actually measures. CVSS, EPSS and CISA's KEV catalog answer three different questions: how bad would this be?, how likely is it to be exploited soon? and has it already been exploited? Mix them up and you patch in the wrong order.

This post is a set of myths I hear (and have believed), each followed by what the primary sources say. At the end there's the simple triage order I use as a starting point for firewalls, VPN gateways and other network devices.

Three filters, three questions. Many CVEs get through CVSS; EPSS and KEV narrow it to the few that go first.

Myth 1: "A CVSS base score of 9.8 means high risk"

Fact: the base score measures severity, not risk.

FIRST, which owns CVSS, says this in plain words. The CVSS v4.0 User Guide has a section titled "CVSS Base Score (CVSS-B) Measures Severity, not Risk", and says base metrics should not be used alone to assess risk. The specification describes the base score as reflecting severity according to its intrinsic characteristics: what the flaw could do, assuming someone exploits it. NIST's NVD is just as direct: "CVSS is not a measure of risk."

Risk needs two more things the base score can't know: whether attackers are using the flaw, and what the affected system means to you. CVSS v4.0, first published on 1 November 2023, makes that gap visible with four metric groups (specification, FIRST v4.0 overview):

Group What it adds Who usually sets it
Base Intrinsic severity: attack vector, complexity, privileges, impact The vendor or another scoring provider
Threat Exploit Maturity: Attacked, Proof-of-Concept, Unreported You (the consumer)
Environmental How much confidentiality, integrity and availability matter for this asset, plus your mitigations You
Supplemental Extra context such as Safety, Automatable, Recovery, Provider Urgency The provider; it never changes the score

The User Guide says applying Threat and Environmental metrics is the responsibility of the CVSS consumer, and that providers typically publish only the base score. v4.0 also asks people to label which groups went into a number: CVSS-B, CVSS-BT, CVSS-BE or CVSS-BTE. The spec says this naming should be used wherever a numerical CVSS value is displayed. When a dashboard shows a bare "9.8", it's almost certainly CVSS-B: a severity number with no knowledge of your network.

A detail worth knowing: if Exploit Maturity is left as "Not Defined", the v4.0 spec treats it as equivalent to Attacked, assuming the worst case. A base score is therefore already pessimistic about threat. Adding real threat data can only keep it the same or bring it down.

Myth 2: "The NVD score is the official score"

Fact: there can be several scores for one CVE, and NVD's role has changed.

NVD publishes only base metrics. It says it does not currently provide assessments for Temporal or Threat metrics, Environmental metrics or Supplemental metrics. On a CVE detail page, NVD shows its own enrichment and, where the CVE Numbering Authority (CNA, often the vendor) supplied one, the CNA's score too. If the two match, only the CNA's is displayed.

Why would they differ? Partly information. When a vendor publishes few details, NVD analysts assign metric values using a worst-case approach, and a CVE with no details at all is assessed as 10.0. The vendor knows its own code and may score lower; NVD, working from the public description, may score higher.

The bigger change came in 2026. From 15 April 2026 NIST enriches CVEs on a risk basis: CVEs in the KEV catalog (with a goal of one business day), CVEs in software used by the federal government, and "critical software" under Executive Order 14028. Everything else is labelled "Lowest Priority - not scheduled for immediate enrichment". NIST also said it will no longer routinely add its own severity score when a CNA has already scored the CVE. The reason is volume: CVE submissions rose 263% between 2020 and 2025, according to the same announcement. And numbers can be wrong. In April 2026 NVD reported that about 4,500 records had an incorrect numerical CVSS v4.0 score, because of an error in how that number was calculated and stored.

The practical lesson: read the vector string, not just the number, and check the vendor's advisory. For a firewall, the advisory usually tells you something the score can't: whether the bug needs a specific feature to be turned on.

Myth 3: "EPSS is just another severity score"

Fact: EPSS estimates likelihood, and says nothing about impact.

The Exploit Prediction Scoring System, maintained by a special interest group at FIRST, is a data-driven model that estimates the probability that a published CVE will be exploited in the wild in the next 30 days. It publishes a score between 0 and 1 for every CVE, every day.

Severity and likelihood are separate dials. A critical CVSS score with a low EPSS score can be correct, and so can the reverse.

The EPSS FAQ is unusually clear about what the model is not (FIRST EPSS FAQ):

  • It does not measure damage. EPSS is the threat-likelihood part of a risk decision, not the whole thing.
  • It doesn't know your environment, your exposure or your compensating controls.
  • Don't multiply EPSS by CVSS. The FAQ says the result is no longer a meaningful probability.
  • CVSS and EPSS are, in the FAQ's words, empirically uncorrelated. So a CVSS 9.8 with a low EPSS score isn't a contradiction. It's two honest answers to two different questions.

Two more points trip people up. First, the probability is absolute and the percentile is relative. Because most CVEs score very low, a probability that looks small can still rank near the top. FIRST suggests showing both together, in a form like "15.3% (92nd)". Second, "exploitation activity" means a data partner detected, recorded and shared evidence of it, so the model only sees what its partners' sensors detect and report.

Myth 4: "If it's not in KEV, it's not being exploited"

Fact: KEV is a list of confirmed exploitation with a high bar, not a list of everything dangerous.

CISA adds a vulnerability to the Known Exploited Vulnerabilities catalog only when three things are true: it has a CVE ID, there is reliable evidence it has been actively exploited in the wild, and there is a clear remediation action, such as a vendor update. "Active exploitation" means evidence that malicious code was run on a system without the owner's permission. Malicious code run on a honeypot counts as attempted exploitation, which qualifies. Scanning, security research and proof-of-concept code don't.

So KEV is strong evidence when a CVE is on it, and weak evidence when it isn't. A brand-new flaw can be exploited before the evidence reaches CISA, and a flaw without a CVE or without a fix can't be listed yet. When I downloaded the JSON feed for this post (catalog version 2026.10.23), it had 1,756 entries, 361 of them marked "Known" for use in ransomware campaigns. That's a small, sharp list compared with the volume of CVEs published every year, which is exactly why it works as a first filter.

Myth 5: "BOD 22-01 says two weeks, so we have two weeks"

Fact: BOD 22-01 was revoked in June 2026; its successor uses decision factors, not one deadline.

The directive that created KEV, BOD 22-01 (3 November 2021), gave US federal agencies two weeks to fix listed vulnerabilities, or six months for CVEs assigned before 2021. Those default timelines could be adjusted in the case of grave risk to the federal enterprise. PAN-OS CVE-2024-3400, for example, was added on 12 April 2024 with a due date of 19 April 2024, one week later.

On 10 June 2026 CISA issued BOD 26-04, "Prioritizing Security Updates Based on Risk", which revokes BOD 22-01 and BOD 19-02 and keeps the KEV criteria. Its Table 1 sets federal remediation deadlines from four questions: is the asset publicly exposed, is the CVE in KEV, can an adversary automate exploitation, and does exploitation give partial or total control? A few rows from that table:

Publicly exposed In KEV Automatable Technical impact Deadline (calendar days)
Yes Yes Yes Total control 3 days and forensic triage
Yes Yes No Partial control 14 days
Yes No No Partial control 60 days
No No No Total control Fix on system upgrade

The directive says the table is informed by SSVC, and the clock starts when CISA adds the CVE to KEV or when the agency identifies it, whichever is first. BOD 26-04 binds only US federal civilian agencies. For everyone else it's a free, well-reasoned template. Notice that "patch" sometimes comes with "check whether you were already compromised".

Myth 6: "We need one number to sort by"

Fact: a decision tree can beat a number.

SSVC (Stakeholder-Specific Vulnerability Categorization) was created by Carnegie Mellon University's Software Engineering Institute in 2019 in collaboration with CISA. Instead of a score, it walks through decision points and lands on an action. CISA's version ends in Track, Track*, Attend or Act. CERT/CC's deployer model ends in Defer, Scheduled, Out-of-cycle or Immediate, with values such as Exploitation (None, Public PoC, Active), Automatable (Yes/No), Technical Impact (Partial/Total) and System Exposure.

One subtle point from CISA's SSVC guide: the Exploitation decision point records the present state and does not predict future exploitation. That's the gap EPSS fills. And since 17 June 2026, CVE records in NVD's data feeds and API include SSVC data from the CISA Authorized Data Publisher alongside CVSS, so the tree's inputs are easier to find than they used to be.

Putting it together: a triage order for network devices

This is my own starting point, not a standard. It borrows the shape of BOD 26-04 and SSVC, and it suits firewalls, VPN gateways and load balancers, because so many of them sit on the internet.

  1. In KEV and reachable from the internet (VPN portal, management interface, any exposed service): act now. Mitigate today if the fix isn't ready, and look for signs of compromise, not just the missing patch.
  2. Not in KEV, but a high EPSS score or a vendor saying it's being exploited, on an exposed interface: out-of-cycle change this week.
  3. Critical or high CVSS-B, automatable, reachable from untrusted networks, and your configuration is affected: next planned change window.
  4. Everything else: normal maintenance, and re-check it when KEV, EPSS or the vendor advisory changes.

A real example of everything lining up: CVE-2024-3400 in PAN-OS GlobalProtect. The vendor gave it CVSS-B 10.0, with Automatable YES and Urgency HIGHEST. KEV lists it with known ransomware use, and its EPSS score was 0.99999 on 24 October 2026. Easy. The hard cases are the ones where the signals disagree, and those are where knowing what each signal measures pays off.

Honest caveats

  • CVSS is only as good as the information behind it. Worst-case defaults inflate scores when details are missing, and a base score knows nothing about your network.
  • EPSS is a model. It depends on what its data partners can see, it covers only CVEs, and it can change daily, so record the date with the score.
  • KEV is conservative by design. Absence isn't safety, and the list reflects what reaches CISA.
  • SSVC and BOD 26-04 need you to know your assets: what is exposed and what it does for the business. That inventory is the work no score can do for you.

The scores aren't the problem. Asking one number to answer three questions is.

Sources

Keep reading

Related posts

Back to blog