Vulnerability scoring and prioritization: CVSS, EPSS and KEV

A large organization's scans can report tens of thousands of open findings at any moment. No team can fix them all at once, and trying to fix them strictly in order of severity score wastes effort on flaws that are never exploited while real threats wait in the queue. Prioritization is the stage of vulnerability management where most of the risk reduction is won or lost. This lesson explains the main scoring systems, what each actually measures, and how to combine them with asset context into a defensible remediation order.

The three widely used public signals answer different questions. The Common Vulnerability Scoring System (CVSS) measures how severe a vulnerability is in technical terms. The Exploit Prediction Scoring System (EPSS) estimates how likely it is to be exploited soon. The Known Exploited Vulnerabilities (KEV) catalog records that it has been exploited in the wild. None of them knows how important the affected system is to your organization; that context has to come from you.

CVSS: severity, not risk

CVSS is maintained by FIRST, the Forum of Incident Response and Security Teams. Version 3.1, published in 2019, remains very widely used; version 4.0 was published in November 2023 and is being adopted by vulnerability databases and vendors, so you will see both. A CVSS base score from 0.0 to 10.0 describes the intrinsic characteristics of a vulnerability, and is mapped to qualitative ratings: none (0.0), low (0.1 to 3.9), medium (4.0 to 6.9), high (7.0 to 8.9) and critical (9.0 to 10.0).

The FIRST specification is explicit that the base score measures severity, not risk. A 9.8 on an isolated test server may matter less than a 6.5 on a payment system exposed to the internet. CVSS 3.1 provides temporal and environmental metric groups to adjust the base score for exploit maturity and for your own environment, but few organizations use them consistently.

The base score is computed from these weights. First the impact sub-score combines the three impacts, then an exploitability sub-score multiplies the four exploitability weights, and finally they are added and rounded up to one decimal place. The formulas below are from the FIRST CVSS v3.1 specification.

If impact is zero or less the base score is 0. Otherwise, for unchanged scope the base score is the impact plus exploitability, capped at 10 and rounded up; for changed scope the sum is multiplied by 1.08 before capping and rounding. The specification defines a precise round-up function to avoid floating-point surprises, which the code below follows.

import math
W = {'AV': {'N': 0.85, 'A': 0.62, 'L': 0.55, 'P': 0.20}, 'AC': {'L': 0.77, 'H': 0.44},
     'UI': {'N': 0.85, 'R': 0.62}, 'CIA': {'H': 0.56, 'L': 0.22, 'N': 0.0}}
def pr(v, changed):
    return {'N': 0.85, 'L': 0.68 if changed else 0.62, 'H': 0.50 if changed else 0.27}[v]
def roundup(x):
    i = round(x * 100000)
    return i / 100000.0 if i % 10000 == 0 else (math.floor(i / 10000) + 1) / 10.0
def base(vector):
    m = dict(p.split(':') for p in vector.split('/')[1:])
    ch = m['S'] == 'C'
    iss = 1 - (1 - W['CIA'][m['C']]) * (1 - W['CIA'][m['I']]) * (1 - W['CIA'][m['A']])
    imp = 7.52 * (iss - 0.029) - 3.25 * (iss - 0.02) ** 15 if ch else 6.42 * iss
    exp = 8.22 * W['AV'][m['AV']] * W['AC'][m['AC']] * pr(m['PR'], ch) * W['UI'][m['UI']]
    if imp <= 0:
        return 0.0
    return roundup(min(1.08 * (imp + exp), 10)) if ch else roundup(min(imp + exp, 10))
def rating(s):
    return 'None' if s == 0 else 'Low' if s < 4 else 'Medium' if s < 7 else 'High' if s < 9 else 'Critical'
for v in ['CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H',
          'CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N',
          'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H',
          'CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N',
          'CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N']:
    s = base(v)
    print(f'{v:46s} {s:4.1f} {rating(s)}')

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H    9.8 Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N    6.1 Medium
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H    7.8 High
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N    5.9 Medium
CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N    4.6 Medium

The first vector, a network-reachable flaw needing no privileges or interaction with high impact on all three properties, scores 9.8, the familiar score of many remote code execution flaws. The second, a typical reflected cross-site scripting pattern with changed scope, scores 6.1. The physical-access example scores much lower even though its confidentiality impact is high. Reading the vector string, not just the number, tells you why a score is what it is.

CVSS 4.0 in brief

CVSS 4.0 keeps the 0 to 10 scale and qualitative bands but changes the metrics and the calculation. It adds an attack requirements metric (AT) alongside attack complexity, splits user interaction into none, passive and active, and replaces scope with separate impact metrics for the vulnerable system (VC, VI, VA) and subsequent systems (SC, SI, SA). Scores are produced from a lookup of 'macrovectors' derived from expert ranking rather than a closed formula, so use the official calculator. Version 4.0 also renames the metric groups, with the threat group (exploit maturity) replacing temporal, and requires labels showing which groups were used: CVSS-B for base only, CVSS-BT with threat, CVSS-BE with environmental and CVSS-BTE with all three. The labels are a useful reminder that a bare base score omits threat and environment.

EPSS: probability of exploitation

EPSS, also run by a FIRST special interest group, estimates the probability that a published CVE will be exploited in the wild in the next 30 days. It is a machine learning model trained on observed exploitation activity and features such as the vulnerability's description, references, availability of exploit code and vendor. Scores range from 0 to 1 and are published daily for every CVE along with a percentile. Version 4 of the model was released in March 2025. EPSS scores move as new evidence appears, so they should be refreshed regularly rather than recorded once.

The striking finding behind EPSS is how few vulnerabilities are ever exploited: most have a very low probability, and a small fraction account for nearly all observed exploitation. Prioritizing by CVSS alone therefore spends most effort on vulnerabilities that will never be used against anyone. EPSS is not a measure of severity or of your exposure; a high EPSS score on a system with no network path to attackers is still lower risk than the same flaw on an exposed server.

KEV: known exploitation

CISA's Known Exploited Vulnerabilities catalog, started in November 2021, lists CVEs with reliable evidence of exploitation in the wild, a clear remediation action and an assigned CVE identifier. It has grown to well over a thousand entries. For United States federal civilian agencies, Binding Operational Directive 22-01 makes listed vulnerabilities mandatory to remediate by stated due dates. Many private organizations in both Canada and the United States treat KEV listing as an automatic top-priority trigger, because it removes guesswork: the flaw is being used. Some vendors and national centres, including the Canadian Centre for Cyber Security through its alerts, publish similar exploitation signals.

Building a risk-based priority

A practical prioritization scheme combines the signals with two pieces of internal context: exposure (is the system reachable from the internet or from untrusted networks?) and criticality (how important are the system and its data?). CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) is one structured approach: a decision tree using exploitation status, technical impact, automatability and mission impact leads to one of four outcomes, track, track*, attend or act. Many organizations use simpler scoring matrices; what matters is that the rule is written down, applied consistently and agreed with system owners.

# Rank findings by a simple, written prioritization rule (illustrative data)
findings = [
    # id, cvss, epss, kev, internet_exposed, asset_criticality(1-3)
    ('F1', 9.8, 0.02, False, False, 1),
    ('F2', 7.5, 0.91, True,  True,  3),
    ('F3', 6.5, 0.45, False, True,  3),
    ('F4', 9.1, 0.01, False, True,  2),
    ('F5', 5.3, 0.88, True,  False, 2),
    ('F6', 8.8, 0.30, False, False, 3),
]
def priority(cvss, epss, kev, exposed, crit):
    likelihood = 1.0 if kev else epss
    score = (cvss / 10) * (0.5 + likelihood) * (1.5 if exposed else 1.0) * (0.75 + 0.25 * crit)
    return round(score, 3)
ranked = sorted(findings, key=lambda f: -priority(*f[1:]))
print('rank id  cvss  epss  kev   exposed crit  priority')
for r, f in enumerate(ranked, 1):
    print(f'{r:>4} {f[0]:3s} {f[1]:4.1f}  {f[2]:4.2f}  {str(f[3]):5s} {str(f[4]):7s} {f[5]:>4}  {priority(*f[1:]):.3f}')

rank id  cvss  epss  kev   exposed crit  priority
   1 F2   7.5  0.91  True  True       3  2.531
   2 F3   6.5  0.45  False True       3  1.389
   3 F6   8.8  0.30  False False      3  1.056
   4 F5   5.3  0.88  True  False      2  0.994
   5 F4   9.1  0.01  False True       2  0.870
   6 F1   9.8  0.02  False False      1  0.510

The ranking differs sharply from a CVSS-only order. F1, the 9.8, falls toward the bottom because it is unlikely to be exploited and sits on an internal, low-criticality system, while F2, a 7.5 that is known exploited and exposed on a critical system, rises to the top. The weights in this rule are invented for illustration; what makes a real rule defensible is that it is documented, consistently applied, reviewed against outcomes and approved by management.