Two findings can share a CVSS Base score and require different response times. The useful question is which evidence justifies that difference.
A queue sorted by CVSS Base alone omits the evidence that can justify different response times. That evidence is known exploitation, forecast exploitation, asset exposure, and decisions already recorded about the finding. These signals do not always agree; prioritization is largely the work of resolving their disagreements and writing down how.
What the Base score measures
CVSS has several metric groups. Base metrics describe a vulnerability’s intrinsic properties: how it can be reached, how hard it is to trigger, what an attacker gains. They are the same for every organization. CVSS v4.0 also defines Threat and Environmental groups so a consumer can adjust for exploit maturity and their own deployment.
FIRST, which maintains the standard, is direct. The CVSS v4.0 User Guide has a section titled “CVSS Base Score (CVSS-B) Measures Severity, not Risk,” and states that Base scores “are designed to measure the severity of a vulnerability and should not be used alone to assess risk.” The specification adds that consumers are expected to enrich Base metrics with Threat and Environmental values, and that factors such as regulatory exposure, customers affected or monetary loss “are outside the scope of CVSS.”
An actively exploited remote code execution flaw on an internet-facing VPN concentrator and a theoretical one on a lab machine behind two firewalls can carry the same Base severity. A queue sorted on that field places them side by side.
The limits of exploitation evidence
Observed exploitation is incomplete evidence. A vulnerability absent from KEV is not proven unexploited, and a low EPSS score is not permission to ignore its consequences in your environment.
FIRST’s EPSS FAQ describes, as a changing observation rather than a fixed rate, seeing “roughly 2.5-3% of published CVEs with exploitation activity” in a 30-day window, and notes that the CISA KEV catalog “lists roughly 0.5% of published CVEs.” Exploitation signals narrow attention far more than a severity sort, but only to what was seen.
CISA KEV: a known-exploited list
The CISA Known Exploited Vulnerabilities catalog is a list, not a score. A vulnerability enters it when it has an assigned CVE ID, when there is “reliable evidence that the vulnerability has been actively exploited in the wild,” and when there is “a clear remediation action for the vulnerability, such as a vendor-provided update.” CISA’s framing is modest: “Organizations should use the KEV catalog as an input to their vulnerability management prioritization framework.”
Treat a KEV match as a strong escalation signal. Determine whether the affected component is present and exposed, then consider business impact, mitigation and any direct evidence of exploitation when assigning urgency. A KEV entry says the vulnerability is being used somewhere, not that your host is reachable or configured as the exploited one.
EPSS: a probability, read correctly
FIRST defines EPSS as “a data-driven model that estimates the probability a vulnerability will be exploited in the wild within the next 30 days.” Scores are published daily with a percentile.
An EPSS probability of 0.10 estimates a 10 percent chance that exploitation activity will be observed in the next 30 days. Its percentile is its position among that day’s scored CVEs, not the probability that your asset will be compromised. FIRST’s FAQ gives the scale: “A 5% probability, when put into context, is ranked in the top 10% of all published vulnerabilities and represents a relatively likely high exploitation forecast.” Lead with the probability; show the percentile beside it.
FIRST’s version history states that EPSS v5 (v2026.06.15) “started publishing 2026-06-15.” As of October 2026, FIRST publishes EPSS v5 scores. Record the score date and model version when using them in reports or historical comparisons. Refresh scores regularly; new information changes the forecast.
Asset context
KEV and EPSS describe the vulnerability; priority belongs to the vulnerability on a specific asset. The minimum context is internet reachability, what the organization loses if the asset is compromised, and what actually runs there. A library installed but never loaded, or a service bound to localhost, is a different exposure from the same service on all interfaces. The scanner reports the package version; the operator knows the deployment.
When the signals conflict
Document how conflicting signals affect the decision. Consider two findings. The first is a KEV-listed vulnerability in a library on an internal application server: installed as a transitive dependency, its vulnerable code path not called by the deployed application, the host reachable only from an administrative network. The second is a vulnerability in a reverse proxy on an internet-facing service: not on KEV, but with a high EPSS probability, and the proxy terminates authentication for a customer-facing system.
Sorted by Base score, the two might be adjacent; sorted by KEV membership alone, the first wins outright. Neither is defensible. The first carries a known-exploitation signal against low applicability and limited exposure; a normal-cycle update may be justified if the applicability evidence holds and no binding deadline requires earlier action; record that decision and its review conditions: “KEV match; component installed but code path unreachable; no external exposure; verified by the application owner.” The second has no KEV listing but a high forecast against full exposure and material consequence; expedite it and record that too: “Not on KEV; EPSS high as of the recorded score date; internet-facing; authentication boundary for customer system.”
The reasons matter because inputs change. If the first finding later appears in an exploitation report naming that code path, or the host moves to a segment with broader access, the reason no longer holds and the finding should move. If the second finding’s forecast falls, the record shows which assumption was time-dependent. A priority with reasons can be re-examined; a bare rank can only be trusted or ignored.
Operational state and recorded decisions
The final input is what the organization has already decided. A finding on a decommissioned host is a stale record. A finding behind a documented compensating control, with the risk acceptance recorded, is not the same priority as an identical finding with no mitigation. A verified false positive should not return to the top because the plugin fired again.
These decisions are evidence and belong next to the priority, as visible as a KEV match. Why they must survive the next scan is covered in a separate article.
In practice
- Check what your queue is sorted by. If it is the CVSS Base score alone, the response-time decision is unexplained.
- Cross-reference open findings against CISA KEV; treat a match as a strong escalation signal, then confirm presence, exposure and business impact before setting urgency.
- Refresh EPSS regularly, show probability with percentile, and record score date and model version in reports.
- Attach asset context to each finding: reachability, business criticality, the component actually exposed.
- Where exploitation, applicability and consequence disagree, write the resolution next to the priority so it can be challenged when inputs change.
Sectie’s Exposure & Vulnerability Management product ranks this way: severity together with CISA KEV, EPSS, asset context and operational state, with the reasons shown next to the priority.
