CVE exploitability triage

A vulnerability scan returns a list. The list is almost always longer than the team's capacity to act on it, and sorting that list by CVSS severity produces a bad ordering: CVSS scores intrinsic technical severity, not the likelihood that anyone will actually attack you through it. The CVSS v3.1 specification says so directly, telling consumers to feed CVSS into "an organizational vulnerability management process that also considers factors that are not part of CVSS" (CVSS v3.1 specification).

This skill supplies those other factors and turns them into an ordering. It takes a list of CVE findings that some scanning step has already produced, enriches each with exploitation signal, and emits a four-bucket priority assignment plus a report.

In scope: which CVEs matter, in what order, and why.

Out of scope: running scanners, parsing per-tool JSON into a common shape, deduplicating findings across tools, the waiver file format, and the CI pass/fail gate. Assume a preceding step handed over a normalized finding list.

The three signals, and what each one does not tell you

CVSS v3.1 qualitative bands, used below wherever this skill says "critical" or "high" (CVSS v3.1 specification):

EPSS is the signal most often misread. FIRST defines it as "a daily estimate of the probability of exploitation activity being observed over the next 30 days" (EPSS model). It is a forward-looking probability with a fixed 30-day horizon, not a rating of how bad the bug is. FIRST is explicit that EPSS "does not account for any specific environmental, nor compensating controls, nor does it make any attempt to estimate the impact of a vulnerability being exploited" (EPSS FAQ). An EPSS of 0.90 on a low-severity information leak still describes a leak.

Each CVE also carries an EPSS percentile: "the proportion of all scored vulnerabilities with the same or a lower EPSS score" (EPSS data and statistics). Probability and percentile answer different questions, and FIRST recommends reporting both together, since a probability of 0.10 already lands near the 88th percentile, which puts it in the top 12% of all scored CVEs (Understanding EPSS probabilities and percentiles).

Step 1 - Establish the finding record

Triage needs six fields per finding. Where they came from does not matter.

interface TriageInput {
  cve: string;              // CVE-2021-44228, or GHSA-xxxx when no CVE was assigned
  package: string;          // ecosystem:name@version
  severity: 'critical' | 'high' | 'medium' | 'low' | 'unknown';
  cvss_base?: number;       // 0.0 - 10.0
  fix_version?: string;     // absent means no fix is published yet
  vex_status?: string;      // populated in Step 4 if a VEX document exists
}

Steps 2 through 5 add epss, epss_percentile, in_kev, kev_due_date, and reachable. Step 6 reads all of them and returns a bucket.

Findings with severity: unknown are treated as medium until a human sets them, so that an unscored CVE cannot silently fall into Accept-Risk.

Step 2 - Enrich with EPSS

Two access paths. Use the bulk CSV in CI (one download covers every CVE in the report) and the API for one-off lookups.

Bulk CSV. FIRST publishes a daily gzipped CSV of every scored CVE at https://epss.empiricalsecurity.com/epss_scores-current.csv.gz, with columns cve, epss, and percentile (EPSS data and statistics):

curl -sSL https://epss.empiricalsecurity.com/epss_scores-current.csv.gz \
  | gunzip > epss.csv

# Header lines start with '#'; the data header is cve,epss,percentile
grep '^CVE-2021-44228,' epss.csv
# CVE-2021-44228,0.94400,0.99950

API. https://api.first.org/data/v1/epss accepts cve (comma separated, up to 2000 characters), date (YYYY-MM-DD, back to 2021-04-14), epss-gt, and percentile-gt (EPSS API):

curl -sS "https://api.first.org/data/v1/epss?cve=CVE-2021-44228,CVE-2019-16759&pretty=true"

The response data[] entries carry cve, epss, percentile, and date (EPSS API).

Two operational rules:

• Scores move daily. FIRST regenerates EPSS every day (EPSS FAQ). Record the date alongside the score in the report so a bucket assignment can be reproduced later. Either refresh the feed per CI run or pin a dated snapshot, but do not mix the two within one report.
• A missing CVE is not a zero. Newly published CVEs and identifiers that are not CVEs at all (GHSA, SNYK, RUSTSEC, and similar advisory IDs) have no EPSS row. Leave epss null and let Step 6 fall through to severity. Substituting 0.0 silently demotes brand-new vulnerabilities, which is exactly backwards.

Step 3 - Enrich with CISA KEV

CISA maintains the KEV catalog as "the authoritative source of vulnerabilities that have been exploited in the wild" (Reducing the significant risk of known exploited vulnerabilities). A CVE is added only when all three thresholds are met, quoted from that page:

1. "The vulnerability has an assigned Common Vulnerabilities and Exposures (CVE) ID."
2. "There is reliable evidence that the vulnerability has been actively exploited in the wild."
3. "There is a clear remediation action for the vulnerability, such as a vendor-provided update."

Criterion 2 is what makes KEV membership decisive. CISA defines active exploitation as reliable evidence that "execution of malicious code was performed by an actor on a system without permission of the system owner", and explicitly excludes scanning, security research, and the mere public availability of a proof of concept (same page). A KEV entry is therefore an observation, not a prediction.

Pull the JSON feed and join on cveID:

curl -sSL -o kev.json \
  https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json

jq -r '.vulnerabilities[]
       | select(.cveID == "CVE-2021-44228")
       | {cveID, dateAdded, dueDate, knownRansomwareCampaignUse, requiredAction}' kev.json

The feed carries top-level title, catalogVersion, dateReleased, and count, and per-entry cveID, vendorProject, product, vulnerabilityName, dateAdded, shortDescription, requiredAction, dueDate, knownRansomwareCampaignUse, notes, and cwes (KEV JSON feed).

Carry three of those fields into the report:

• dueDate is CISA's own remediation deadline for that entry. Federal civilian executive branch agencies are required to remediate KEV entries within the prescribed timeframes under BOD 26-04, which carries the KEV catalog criteria forward from BOD 22-01; other organizations are not bound by it but CISA strongly recommends treating KEV entries the same way (Reducing the significant risk of known exploited vulnerabilities). Use dueDate as the external deadline in the report even when the team is not federal.
• knownRansomwareCampaignUse is Known or Unknown. Known justifies escalating past a normal Fix-Now queue.
• requiredAction is the concrete remediation CISA verified exists, which is useful when the scanner reports no fix version.

Some vulnerability databases already flag KEV membership inline, and NVD annotates CVE detail pages with a KEV reference and link (NVD on the CISA exploited-vulnerabilities catalog). Prefer the CISA feed as the source of truth; use inline scanner flags only to cross-check.

Step 4 - Apply VEX assertions

A VEX document is the product owner's statement about whether their product is actually affected by a CVE present in its dependency graph. OpenVEX defines exactly four status labels (OpenVEX specification):

A valid statement needs one or more products, a vulnerability identifier, a status label, and a timestamp (same specification).

The rule that matters for triage: for not_affected, a VEX statement "MUST include either a status justification or an impact_statement informing why the product is not affected by the vulnerability" (same specification). The five machine-readable justifications are component_not_present, vulnerable_code_not_present, vulnerable_code_not_in_execute_path, vulnerable_code_cannot_be_controlled_by_adversary, and inline_mitigations_already_exist (same specification).

So:

def apply_vex(finding, statement):
    if statement["status"] != "not_affected":
        finding["vex_status"] = statement["status"]
        return finding
    if not (statement.get("justification") or statement.get("impact_statement")):
        finding["vex_status"] = "affected"           # spec-invalid; refuse the claim
        finding["vex_rejected"] = "not_affected without justification"
        return finding
    finding["vex_status"] = "not_affected"
    finding["vex_justification"] = statement.get("justification") \
                                   or statement["impact_statement"]
    return finding

An unjustified not_affected is worse than no assertion at all, because it looks like analysis. Reject it and bucket the finding as if the VEX document did not exist.

Set-aside findings still appear in the report with their justification text. The audit trail is the point: a reviewer must be able to check that vulnerable_code_not_in_execute_path was true when it was claimed.

Step 5 - Reachability heuristic

Reachability asks whether the vulnerable code is on any path the application can execute. When a language toolchain can answer this properly, use it. Go's govulncheck "reduces noise by prioritizing vulnerabilities in functions that your code is actually calling" (govulncheck announcement), which is a call-graph answer rather than a guess.

Without call-graph analysis, these signals approximate it:

Three constraints on using this signal:

1. It deprioritizes, it never exonerates. Static tools miss dynamic imports, reflection, plugin loaders, and shell-outs. depcheck, the long-standing npm equivalent, warns in its own README that "the predefined rules may not be enough or may even be wrong" (depcheck); that repository was archived on 2025-06-16 and points users to knip. Treat reachable: false as a reason to move a finding down one bucket, not to close it.
2. It never applies to a KEV entry. See Step 7.
3. Record which tool produced it. A reachability claim with no named tool and no command is an opinion, and it will be re-litigated at the next scan.

Step 6 - Assign a priority bucket

KEV_BUCKET          = 'Fix-Now'
EPSS_CRITICAL_GATE  = 0.5   # critical severity escalates to Fix-Now above this
EPSS_HIGH_GATE      = 0.3   # high severity holds Fix-This-Sprint above this

def priority(f):
    if f.get('vex_status') == 'not_affected':
        return 'Set-aside-VEX'          # reported, not bucketed, not blocking
    if f.get('in_kev'):
        return KEV_BUCKET               # observed exploitation; no other signal overrides
    epss = f.get('epss') or 0.0
    if f['severity'] == 'critical' and epss > EPSS_CRITICAL_GATE:
        return 'Fix-Now'
    if f['severity'] == 'critical':
        return 'Fix-This-Sprint'
    if f['severity'] == 'high' and epss > EPSS_HIGH_GATE:
        return 'Fix-This-Sprint'
    if f.get('reachable') is False:
        return 'Fix-Backlog'            # demoted one step, never closed
    if f['severity'] == 'high':
        return 'Fix-This-Sprint'
    if f.get('fix_version') is None and f['severity'] in ('medium', 'low'):
        return 'Accept-Risk'            # no fix exists and impact is bounded
    if f['severity'] == 'medium':
        return 'Fix-Backlog'
    return 'Accept-Risk'

Bucket meanings:

Why these two EPSS numbers. FIRST states plainly that EPSS "thresholds represent statements of risk tolerance" (EPSS model), so any cut point is a policy choice, not a fact. These two are chosen for where they sit in the distribution: a probability of 0.10 is already near the 88th percentile (Understanding EPSS probabilities and percentiles), so 0.3 and 0.5 sit far into the tail and fire on a small minority of findings. That is the intent. A gate that fires on a third of the report is not a gate.

Tune by measuring, not by feel: lower EPSS_HIGH_GATE and the Fix-This-Sprint queue grows, raise it and more genuinely exploitable CVEs slip to backlog. Record the values in the report so a reader knows which policy produced the ordering.

Prefer probability for gating, percentile for communicating. Percentiles shift as the corpus grows, so a percentile-based gate quietly changes meaning over time. Report both, gate on the probability (Understanding EPSS probabilities and percentiles).

Step 7 - The KEV rule: a KEV CVE is never waivable

Hard rule. A CVE listed in the CISA KEV catalog cannot be waived, suppressed, snoozed, marked accepted-risk, or filtered out by any exception mechanism, for any stated reason, by any approver.

The justification is in the catalog's inclusion criteria. KEV membership means CISA holds reliable evidence that an actor executed malicious code against this vulnerability on a system without the owner's permission, and that a clear remediation action exists (Reducing the significant risk of known exploited vulnerabilities). Every argument normally offered for a waiver has already been answered:

A not_affected VEX assertion is the one adjacent case, and it is not a waiver: it is a technical claim with a required justification (Step 4) that must name which of the five OpenVEX justifications applies. Hold it to a higher bar for KEV entries: require the justification, a named reviewer, and evidence, and if any of the three is missing, bucket as Fix-Now.

When a KEV entry genuinely cannot be patched today, the answer is compensating action, not an exception: pin to the requiredAction mitigation, remove the dependency, disable the affected feature, or isolate the component at the network boundary. Record the compensating control and the patch date. Never record it as accepted risk.

Worked example

Six findings arrive from a scan of an image and its application dependencies.

Input, before enrichment:

After Steps 2 through 5:

Walking Step 6:

• CVE-2021-44228 hits the in_kev branch first, so Fix-Now. The reachable: false claim from knip is recorded in the report and changes nothing, per Step 7. The team cannot waive this one.
• CVE-2024-A is critical with EPSS 0.83, above EPSS_CRITICAL_GATE of 0.5, so Fix-Now.
• CVE-2024-B is high with EPSS 0.45, above EPSS_HIGH_GATE of 0.3, so Fix-This-Sprint. It reaches that branch before the reachability check, which is intentional: a strong exploitation signal outranks a heuristic.
• CVE-2024-C is high but EPSS 0.006 is below the gate, and it is unreachable, so it falls to Fix-Backlog. Severity alone would have called it urgent.
• CVE-2024-D is medium with no fix published, so Accept-Risk. It goes on the scheduled re-review list, because a fix may appear.
• CVE-2024-E carries a valid not_affected with a listed OpenVEX justification, so Set-aside-VEX. Had the justification field been empty, it would have been rejected in Step 4 and bucketed high with EPSS 0.22, which is below the gate, therefore Fix-This-Sprint.

Result: 2 Fix-Now, 2 Fix-This-Sprint, 1 Fix-Backlog, 1 Accept-Risk, 1 set aside. Severity-only sorting would have put four of these in the same urgent pile and buried CVE-2024-D entirely.

Expected output

## CVE exploitability triage - build a1b2c3d

**Signals:** EPSS 2026-07-19 snapshot, KEV catalogVersion 2026.07.16,
VEX sbom.openvex.json
**Policy:** critical escalates above EPSS 0.5; high holds above EPSS 0.3
**Findings triaged:** 6 (1 set aside by VEX)

### Fix-Now (2)

| CVE | Package | CVSS | EPSS (pct) | KEV | Reachable | Fix | Deadline |
|---|---|---|---|---|---|---|---|
| CVE-2021-44228 | log4j-core@2.14.1 | 10.0 | 0.944 (99.9) | yes | false* | 2.17.1 | KEV dueDate 2021-12-24 |
| CVE-2024-A | example-parser@1.2.3 | 9.8 | 0.830 (99.4) | no | true | 1.2.5 | before merge |

\* Reachability recorded for context only. KEV entries are not waivable and are
not demoted by a reachability heuristic.

### Fix-This-Sprint (2)

| CVE | Package | CVSS | EPSS (pct) | Fix | Why |
|---|---|---|---|---|---|
| CVE-2024-B | http-util@3.4.5 | 7.5 | 0.450 (96.8) | 3.4.6 | high severity above EPSS gate 0.3 |

### Fix-Backlog (1)

| CVE | Package | CVSS | EPSS (pct) | Reachable | Why |
|---|---|---|---|---|---|
| CVE-2024-C | date-fmt@2.0.0 | 7.2 | 0.006 (72) | false (knip) | below EPSS gate and unreachable |

### Accept-Risk (1)

| CVE | Package | CVSS | EPSS (pct) | Why accepted | Re-review |
|---|---|---|---|---|---|
| CVE-2024-D | image-codec@0.9.0 | 5.3 | 0.001 (34) | medium, no fix published | 2026-10-19 |

### Set aside by VEX (1)

| CVE | Package | Status | Justification | Asserted by |
|---|---|---|---|---|
| CVE-2024-E | shell-wrap@5.1.0 | not_affected | vulnerable_code_not_in_execute_path | platform-team, 2026-07-01 |

### Action items

1. CVE-2021-44228 in log4j-core: KEV entry, upgrade to 2.17.1. Not waivable.
2. CVE-2024-A in example-parser: critical at 99.4th EPSS percentile, upgrade to 1.2.5.
3. Re-review CVE-2024-D on 2026-10-19 in case a fix ships.

Two report properties matter more than the layout: every bucket names the rule that produced it, and every signal names its snapshot date. Both exist so the ordering can be re-derived and argued with later.

Anti-patterns

Limitations

• KEV is a floor, not a ceiling. It lists only what CISA has confirmed and for which a remediation exists (Reducing the significant risk of known exploited vulnerabilities). Plenty of real exploitation never appears in it. A CVE that is absent from KEV is not thereby safe.
• EPSS is a global model. It carries no knowledge of the deployment, the network position, or any compensating control in place (EPSS FAQ). It cannot tell you whether the affected service is internet-facing.
• EPSS scores drift daily (EPSS FAQ), so the same finding can change bucket between two runs with no code change. Snapshot pinning makes this visible instead of confusing.
• Non-CVE advisory identifiers have no EPSS and no KEV entry. GHSA, RUSTSEC, and vendor-specific IDs fall through to severity-only handling unless they carry a CVE alias.
• Reachability is heuristic outside call-graph tooling. Only ecosystems with real call analysis, such as Go via govulncheck (govulncheck announcement), give a defensible answer.
• VEX is only as good as the analysis behind it. A justification field proves someone typed a reason, not that the reason is true. Spot-check vulnerable_code_not_in_execute_path claims against the code.
• The Accept-Risk bucket grows without bound unless every entry carries a re-review date and someone owns the schedule.