If your patch pipeline uses an EPSS cutoff to decide what is urgent, it will miss about a quarter of CISA’s Known Exploited Vulnerabilities (KEV) catalog, and roughly half of the entries CISA added in the last 90 days. Joining KEV catalog 2026.11.06 to the EPSS file for November 6, 2026, 436 of 1,768 scored KEV CVEs sit below 0.1. Tracking recent additions day by day shows why: EPSS scores for newly listed CVEs typically start low and take about two weeks to cross 0.1, which is the window in which a KEV listing matters most.

We argued in our CVSS vs EPSS vs KEV comparison that KEV should be checked before EPSS. This article measures what happens when it is not, and gives you a script to test your own cutoff.

The snapshot: KEV CVEs below common EPSS cutoffs

Data: the KEV JSON (catalog version 2026.11.06, released 2026-11-06T19:44Z, 1,769 entries) and the EPSS daily file for November 6, 2026 (model_version:v2026.06.15, 400,985 scored CVEs). One KEV entry, CVE-2026-19868, added that day, had no EPSS score yet.

The median KEV CVE scores 0.536 (99.0th percentile), so the typical entry is well above any cutoff. The problem is the tail, and the tail is not random. If you are unsure what the epss and percentile columns mean, our EPSS data feed guide covers them.

Newest KEV entries score lowest

Split by dateAdded, the share below 0.1 falls as entries age:

Several recent listings we covered are in that first row. On November 6, WordPress CVE-2026-119977 (added November 3) scored 0.0116, Ivanti CVE-2026-111357 and CVE-2026-118527 (added October 30) scored 0.0053 and 0.0082, and VMware ESX CVE-2026-41709 (added October 28) scored 0.0069. Each would sit below even a 0.05 cutoff.

Tracking the lag: 113 KEV additions, day by day

A snapshot cannot show whether low scores are permanent or just early. So we took the 113 KEV entries added between June 16 and October 7, 2026, and looked up each one in every daily EPSS file from June 15 to November 6 (145 files). That window starts the day after EPSS v5 replaced v4, so every score comes from the same model (v2026.06.15); our EPSS v5 analysis explains why mixing models would distort this. The October 7 end date gives every entry at least 30 days of follow-up.

Notes on reading it:

• Missing scores are real. 36 of the 113 had no EPSS score the day before listing and 22 had none on the day itself, usually because the CVE had only just been published. By day 7 all 113 were scored.
• Crossing time. 15 entries were already at or above 0.1 the day before listing. Of the rest, 64 crossed 0.1 later, after a median of 14 days (23 within a week). 34 had not reached 0.1 by November 6, 36 to 115 days after listing.
• Timing, not cause. EPSS files publish only the score. We cannot see which inputs moved a score, so we do not claim the KEV listing itself caused any rise.

Why the gap exists is consistent with how each list is built. CISA adds a CVE when there is “reliable evidence that the vulnerability has been actively exploited in the wild” (CISA). EPSS is “the probability [0-1] of exploitation in the wild in the next 30 days (following score publication)”, estimated from data (EPSS scores README). The community Risk Based Prioritization guide puts it this way: EPSS reflects “the automated data we receive and collect”, while KEV is “a list of human curated CVEs with historical exploitation activity”, so a CVE can be in one and score low in the other. It also quotes FIRST’s EPSS FAQ: where exploitation is evidenced, “that information should supersede anything EPSS has to say”.

What to change in a pipeline

These are our recommendations from the data above; we have not measured them on anyone’s backlog.

1. Route on KEV membership before any EPSS rule. A listed CVE goes to the urgent queue whatever its score. This is the first step in our prioritization workflow.
2. Do not “promote” KEV entries by adding a bonus to the EPSS score. A bonus sized for the median KEV entry (0.536) does nothing for an entry at 0.005.
3. Treat a missing EPSS score as “unknown”, not zero. 22 of the 113 entries had no score on the day they were listed. A join that fills nulls with 0 drops exactly those.
4. Refresh KEV more often than you refresh thresholds. The KEV JSON feed updates on listing days; the lag above means the KEV check is doing nearly all of the work for the first two weeks.
5. Re-run the audit after every EPSS model change, since cutoffs shift with the model.

Audit your own cutoff

This script joins the two public files and reports how many KEV entries your cutoff misses, by listing age. We ran it with Python 3.12 on the files named above; the output below is for 0.1.

#!/usr/bin/env python3
"""How many CISA KEV entries would an EPSS cutoff miss?
usage: kev_epss_audit.py known_exploited_vulnerabilities.json epss_scores-YYYY-MM-DD.csv.gz CUTOFF"""
import csv, gzip, json, sys
from datetime import date

kev_path, epss_path, cutoff = sys.argv[1], sys.argv[2], float(sys.argv[3])
catalog = json.load(open(kev_path))
with gzip.open(epss_path, "rt") as f:
    header = f.readline().strip()                 # "#model_version:...,score_date:..."
    scores = {r["cve"]: float(r["epss"]) for r in csv.DictReader(f)}
score_day = date.fromisoformat(header.split("score_date:")[1][:10])

print(f"KEV catalog {catalog['catalogVersion']}, EPSS {header[1:]}, cutoff {cutoff}")
buckets = {"added <= 90 days ago": [], "91-365 days": [], "over 1 year": []}
unscored = []
for v in catalog["vulnerabilities"]:
    if v["cveID"] not in scores:
        unscored.append(v["cveID"])
        continue
    age = (score_day - date.fromisoformat(v["dateAdded"])).days
    name = "added <= 90 days ago" if age <= 90 else "91-365 days" if age <= 365 else "over 1 year"
    buckets[name].append((v["cveID"], scores[v["cveID"]]))

total = below = 0
for name, rows in buckets.items():
    n_below = sum(1 for _, s in rows if s < cutoff)
    total += len(rows); below += n_below
    print(f"{name:22} {len(rows):5} KEV CVEs, {n_below:4} below cutoff ({n_below/len(rows):.1%})")
print(f"{'all scored':22} {total:5} KEV CVEs, {below:4} below cutoff ({below/total:.1%})")
print(f"not in EPSS file: {len(unscored)} {unscored[:5]}")

$ python3 kev_epss_audit.py known_exploited_vulnerabilities.json epss_scores-2026-11-06.csv.gz 0.1
KEV catalog 2026.11.06, EPSS model_version:v2026.06.15,score_date:2026-11-06T12:00:23Z, cutoff 0.1
added <= 90 days ago     106 KEV CVEs,   52 below cutoff (49.1%)
91-365 days              207 KEV CVEs,   57 below cutoff (27.5%)
over 1 year             1455 KEV CVEs,  327 below cutoff (22.5%)
all scored              1768 KEV CVEs,  436 below cutoff (24.7%)
not in EPSS file: 1 ['CVE-2026-19868']

Get the KEV file from raw.githubusercontent.com/cisagov/kev-data/main/known_exploited_vulnerabilities.json and the EPSS file from the empiricalsec/epss_scores repository (one gzip file per day under the year folder). The script reads the whole EPSS file into memory, which is fine for about 400,000 rows.

Limits of this article

The snapshot is one day (November 6, 2026). The day-by-day sample is 113 entries over one model version, which is enough to show a pattern but not to estimate a precise lag for any vendor or CVE type. “Day of listing” compares KEV dateAdded to the EPSS file of the same date; their publication times within the day differ. We did not examine why the 34 entries that stayed below 0.1 scored as they did.

Sources and verification

The EPSS daily file changed models on June 15, 2026. The first line of the June 14 file reads #model_version:v2025.03.14 (v4). The June 15 file reads #model_version:v2026.06.15 (v5). We compared those two files, which together hold 340,204 CVEs scored on both days. If your pipeline gates on a fixed EPSS probability, it lost about a quarter of its flagged CVEs overnight: 23,069 CVEs scored 0.1 or higher under v4 and 17,041 under v5. Nothing about those vulnerabilities changed that day; the model did.

This article covers what changed in v5, what the shift looks like in the data, and what to re-baseline. For the file format itself (columns, header line, how to join it to a scanner export), see our EPSS data feed guide. That guide already lists the five model versions and their start dates; this one measures the most recent change.

What changed in v5

Empirical Security, which runs the EPSS model and hosts the data, announced EPSS V5 on May 13, 2026. The release says v5 “incorporates improved modeling techniques and optimization algorithms” and that “the calibration step has been refined.” It also cites a better classifier for published exploit code and “the addition of new data feeds.”

The headline claim is a 23% improvement. Empirical’s research post defines the metric only loosely, as one that rewards “ranking genuinely exploited vulnerabilities above ones that pose no real threat.” On data from May 4, 2026, it reports that v4 scored 0.514 and v5 scored 0.633, where “a random guess would score around 0.025, and a perfect model would score 1.0.” We did not reproduce that evaluation.

The rollout is visible in the public empiricalsec/epss_scores repository:

The beta files carry a different model label (v2026.05.12) from the production model, so treat beta scores as a preview of v5, not as v5 itself. The repository README lists the model changes for v2, v3 and v4 but, as of November 6, 2026, has no v5 entry. The file header was the reliable signal.

The CSV format did not change. Both files have the same comment line followed by cve,epss,percentile.

How the scores moved

We loaded 2026/epss_scores-2026-06-14.csv.gz and 2026/epss_scores-2026-06-15.csv.gz from the repository and compared CVEs present in both. For a baseline, we ran the same comparison on June 13 and June 14, two consecutive v4 days.

Three patterns stand out.

The distribution got narrower. The lowest v4 score was 0.00001 and 93,484 CVEs sat below 0.001. Under v5 the minimum is 0.00046 and only 3,552 CVEs are below 0.001. At the top end, the 99th percentile fell from 0.772 to 0.595. The median ratio of v5 to v4 score was 2.89: most low-scored CVEs went up, while many of the high scorers came down. That fits the release’s description of recalibration, but the release does not say this is the intended effect, so treat it as our reading of the data.

Fixed cutoffs shrank. A rule like epss >= 0.1 matched 26.1% fewer CVEs the day v5 went live, and epss >= 0.5 matched 40.9% fewer. Of the CVEs that crossed 0.1, 9,847 dropped below it and only 3,820 rose above it.

Percentile rules kept their size, not their members. A percentile is a rank, so the 90th-percentile bucket stays about 10% of scored CVEs. But 9,837 CVEs entered it and 9,944 left it in one day, compared with 25 and 29 on a normal v4 day. If you track “new CVEs in the top decile” as a work queue, June 15 would have looked like a flood.

1,146 CVEs scored on June 14 were missing from the June 15 file and 43 appeared for the first time. By November 5, all but 119 of the missing ones were back in the feed. We did not establish why they were absent that day.

What happened to KEV-listed CVEs

To see whether v5 demoted known-exploited vulnerabilities, we took the CISA KEV catalog (catalog version 2026.11.04) and kept only the 1,619 entries whose dateAdded is on or before June 14, 2026, so the set matches what was known on the switch date. All 1,619 were scored on both days.

The probability for KEV entries came down along with the rest of the high end. But almost the same number cleared 0.1, and more of them landed in the top decile. KEV-listed CVEs that a 0.1 rule already caught were still caught. A rule set to 0.5 or 0.7 on the assumption that KEV CVEs sit there would have lost many of them, since the median is now about 0.54.

This is one reason KEV should stay a separate input instead of being folded into an EPSS cutoff. Our CVSS vs EPSS vs KEV comparison covers why; the prioritization workflow shows where each signal sits in the patch decision.

What to re-baseline

These are our recommendations, based on the data above. We have not measured their effect on any team’s backlog.

1. Find every fixed probability cutoff. SLA rules, ticket triggers, dashboard colours and scanner policies. If one was tuned against v4 data, check how many CVEs it matches today versus before June 15.
2. Decide what the cutoff is for. If it sizes a queue (“the top few thousand CVEs”), switch it to a percentile. If it expresses risk (“at least a 10% chance of exploitation in 30 days”), keep the probability, because v5’s calibration is meant to make that reading more accurate, but accept that the queue size will move.
3. Do not compare scores across the switch. A CVE that went from 0.4 to 0.2 on June 15 did not become less likely to be exploited that day. If you chart EPSS history, mark June 15, 2026 (and the earlier switches on 2022-02-04, 2023-03-07 and 2025-03-17).
4. Keep KEV as an override. Do not rely on EPSS to bring KEV entries above a high cutoff.
5. Store model_version next to every score. Then you can always tell which model produced a score your system acted on.

A guard for the next model change

There is no API callback when the model changes, but the file tells you. This script compares the header of yesterday’s and today’s file and exits non-zero on a model change, so a CI job or cron wrapper can stop before ingesting.

"""Stop an EPSS ingest when the model version changes.
Usage: python3 epss_model_guard.py yesterday.csv.gz today.csv.gz"""
import gzip, sys

def header(path):
    with gzip.open(path, "rt") as f:
        first = f.readline().strip()
    if not first.startswith("#"):
        return {"model_version": "pre-v2 (no header)", "score_date": ""}
    return dict(kv.split(":", 1) for kv in first.lstrip("#").split(","))

old, new = header(sys.argv[1]), header(sys.argv[2])
print(f"previous: {old['model_version']} scored {old['score_date']}")
print(f"current:  {new['model_version']} scored {new['score_date']}")
if old["model_version"] != new["model_version"]:
    print("MODEL CHANGE: hold threshold-based alerts and re-baseline before ingesting")
    sys.exit(2)

We ran it with Python 3 against files from the repository:

$ python3 epss_model_guard.py epss_scores-2026-06-14.csv.gz epss_scores-2026-06-15.csv.gz
previous: v2025.03.14 scored 2026-06-14T12:55:00Z
current:  v2026.06.15 scored 2026-06-15T12:03:41Z
MODEL CHANGE: hold threshold-based alerts and re-baseline before ingesting
exit=2

$ python3 epss_model_guard.py epss_scores-2026-11-04.csv.gz epss_scores-2026-11-05.csv.gz
previous: v2026.06.15 scored 2026-11-04T12:03:12Z
current:  v2026.06.15 scored 2026-11-05T12:03:04Z
exit=0

When the guard trips, run the same comparison we did above (counts at your cutoffs, percentile churn, KEV coverage) before you turn alerts back on. Note the score_date format also changed with v4 (from +0000 offsets to Z), so parse it as ISO 8601 instead of matching a fixed string.

Limits of this article

• We compared one pair of days. Scores on later v5 days have kept moving as new signals arrive, so today’s counts differ from June 15.
• The 23% improvement figure and the description of model changes come from Empirical Security. We did not test model accuracy.
• KEV is a list of vulnerabilities known to be exploited, not a ground truth for EPSS’s 30-day prediction window, so the KEV table shows coverage, not accuracy.
• We did not find a FIRST page describing v5 in the sources we could reach. If FIRST publishes a different start date or model description, the file headers above are still what your pipeline will see.

Sources and verification

Scope. This is a workflow guide built on public specifications and feeds, plus one script we ran. On November 2, 2026 we read the CVE JSON schema (5.2.0), CISA’s Vulnrichment README, CERT/CC’s SSVC deployer documentation and decision table, the OpenVEX specification and the EPSS repository README, and ran the script below against the KEV catalog (version 2026.10.30), the EPSS file scored 2026-11-01 and CVE records from cvelistV5. The assets, exposure ratings and the VEX document in the test are invented for the demonstration. The policy choices in the script are ours, not a standard.

The workflow in one table

Our comparison of CVSS, EPSS and KEV explains what each signal measures. This guide is the plumbing: the order in which a finding from a scanner or SBOM passes through the data, and what lands in the ticket.

Steps 1 to 3 remove work. Steps 4 to 6 order what remains.

Step 1: check the record state

A CVE record is either PUBLISHED or REJECTED (the schema’s two states), and published records can carry tags such as disputed. A rejected ID has no affected products to evaluate. In our test run, CVE-2026-23915 is a Fortinet-assigned ID that was rejected on January 20, 2026 with the reason “Not used”, so the finding closes. Our guide to CVE record states covers the tags and edge cases.

Step 2: confirm you are affected

The CNA’s affected block is an algorithm, not a list: walk versions, take the first match, otherwise use defaultStatus, and if that is missing the schema says the status is unknown. Scanner results that only match a product name skip this. Our explainer on CVE affected versions shows how lessThan, defaultStatus and versionType combine, with a tested evaluator. Keep three outcomes apart in the ticket: affected, unaffected, and unknown or undetermined. The last needs a person or the vendor advisory.

Step 3: apply supplier VEX

If the vulnerable component ships inside someone else’s product, the supplier may publish a VEX (Vulnerability Exploitability eXchange) statement. OpenVEX defines four statuses: not_affected (“No remediation is required regarding this vulnerability”), affected, fixed and under_investigation. A not_affected statement must carry a justification or an impact statement.

Two cautions. A VEX statement is about a specific product and version, so match on the product identifier, not on the CVE alone; a not_affected statement from an appliance vendor says nothing about your own services that use the same library. And read the justification before closing. Our guide to reading a VEX not-affected statement covers the five justifications and what to question.

Step 4: read the exploitation evidence

Two public sources answer “is this being exploited?”:

• KEV. The CISA KEV JSON feed lists CVEs with evidence of exploitation, with dateAdded, dueDate, knownRansomwareCampaignUse and, on newer entries, forensicTriage. The catalog we used (version 2026.10.30, released October 30, 2026) had 1,766 entries.
• CISA’s SSVC values in the CVE record. CISA’s Vulnrichment project writes three SSVC decision points (Exploitation, Automatable, Technical Impact) into a CISA-ADP container. Its README says CISA is “assessing new and recent CVEs”, and that it will not overwrite the CNA’s data. Each value set carries a timestamp. Our Vulnrichment guide shows where they sit and how to pull them with jq.

The SSVC documentation describes Exploitation as “the present state of exploitation”, not a prediction. A none from months ago can be stale, so a KEV listing should outrank an older ADP value. That is the rule our script applies.

Step 5: add EPSS for likelihood

For findings with no exploitation evidence, EPSS estimates “the probability [0-1] of exploitation in the wild in the next 30 days”, and percentile gives the share of scored CVEs with the same or a lower score. The file we used (model v2026.06.15, scored 2026-11-01) held 398,784 CVEs. EPSS is a ranking aid within the non-exploited queue. It does not replace step 4: in our run the KEV-listed FortiMail flaw scored 0.04573. See the EPSS data feed guide for the columns, model-version breaks and a scanner join.

Step 6: let exposure and impact decide

CERT/CC’s SSVC deployer model maps four inputs to a patch priority:

The decision table (deployer_patch_application_priority_1_0_0.csv, 72 rows) returns one of four outcomes, which the deployer documentation defines as: Defer (“Do not act at present”), Scheduled (“Act during regularly scheduled maintenance time”), Out-of-cycle (“Act more quickly than usual… during the next available opportunity”) and Immediate (“Act immediately; focus all resources on applying the fix”). In the table, Immediate appears in 3 rows, all with active exploitation and open exposure. Our SSVC deployer explainer walks through the inputs, including where Human Impact is easy to get wrong.

One mapping detail: CISA’s ADP data writes poc, while the deployer table uses public poc. They are not identical definitions. CISA’s tree uses the older PoC value, which also covers privately attested exploitation and widespread hearsay; the newer Public PoC value covers only public exploit code or a well-known method. Our script maps one to the other, which can understate cases CISA marked poc on private evidence.

A tested script that writes the ticket fields

The script reads a findings CSV, the KEV JSON, the EPSS daily file, the SSVC deployer CSV, a folder of CVE records and an optional OpenVEX file, and prints one ticket row per finding. Python 3.10 or later, standard library only.

#!/usr/bin/env python3
"""Turn scanner findings into patch-decision ticket rows.

Inputs : findings.csv (asset,product,cve,exposure,human_impact)
         KEV JSON, EPSS daily CSV (.csv.gz), SSVC deployer table CSV,
         a directory of cvelistV5 records, optional OpenVEX file.
Output : tickets.csv on stdout. Python 3.10+, standard library only.
"""
import csv, gzip, json, sys, argparse, pathlib

def load_kev(path):
    data = json.load(open(path))
    return {v["cveID"].strip().upper(): v for v in data["vulnerabilities"]}

def load_epss(path):
    scores = {}
    with gzip.open(path, "rt") as fh:
        rows = (line for line in fh if not line.startswith("#"))
        for r in csv.DictReader(rows):
            scores[r["cve"]] = (float(r["epss"]), float(r["percentile"]))
    return scores

def load_deployer(path):
    rows = list(csv.reader(open(path)))
    return {tuple(r[1:5]): r[5] for r in rows[1:]}

def load_vex(path):
    out = {}
    if path:
        for s in json.load(open(path)).get("statements", []):
            for p in s.get("products", []):
                out[(s["vulnerability"]["name"].upper(), p["@id"])] = s
    return out

def cisa_ssvc(record):
    """Return CISA ADP SSVC values (Exploitation, Automatable, Technical Impact, timestamp)."""
    for adp in record["containers"].get("adp", []):
        for m in adp.get("metrics", []):
            other = m.get("other", {})
            if other.get("type") == "ssvc":
                c = other["content"]
                opts = {k: v for o in c["options"] for k, v in o.items()}
                return (opts.get("Exploitation"), opts.get("Automatable"),
                        opts.get("Technical Impact"), c.get("timestamp"))
    return (None, None, None, None)

def main():
    ap = argparse.ArgumentParser()
    for a in ("findings", "kev", "epss", "deployer", "records"):
        ap.add_argument(a)
    ap.add_argument("--vex")
    args = ap.parse_args()
    kev, epss = load_kev(args.kev), load_epss(args.epss)
    table, vex = load_deployer(args.deployer), load_vex(args.vex)
    out = csv.writer(sys.stdout)
    out.writerow(["asset", "cve", "record_state", "vex_status", "kev_dateAdded",
                  "kev_dueDate", "kev_ransomware", "cisa_exploitation", "cisa_automatable",
                  "cisa_technical_impact", "cisa_ssvc_timestamp", "epss", "epss_percentile",
                  "deployer_exploitation", "deployer_priority", "next_step"])
    for f in csv.DictReader(open(args.findings)):
        cve = f["cve"].strip().upper()
        rec_path = pathlib.Path(args.records) / f"{cve}.json"
        if not rec_path.exists():
            out.writerow([f["asset"], cve, "NO RECORD"] + [""] * 12 + ["check the ID"])
            continue
        rec = json.load(open(rec_path))
        state = rec["cveMetadata"]["state"]
        if state == "REJECTED":
            out.writerow([f["asset"], cve, state] + [""] * 12 + ["close: CVE ID rejected"])
            continue
        v = vex.get((cve, f.get("product", "")), {})  # VEX applies to one product, not every asset
        k = kev.get(cve, {})
        exp, auto, ti, ts = cisa_ssvc(rec)
        e, pct = epss.get(cve, ("", ""))
        # Our policy choice: a KEV listing counts as active exploitation, whatever
        # the (possibly older) CISA ADP snapshot says. CISA writes "poc"; the
        # deployer table writes "public poc".
        dexp = "active" if k else {"poc": "public poc"}.get(exp, exp)
        prio = ""
        if dexp and auto:
            prio = table.get((dexp, f["exposure"], auto, f["human_impact"]), "")
        if v.get("status") == "not_affected":
            step = "close: supplier VEX not_affected (" + v.get("justification", "no justification") + ")"
        elif not prio:
            step = "manual triage: no CISA SSVC data"
        else:
            step = prio
        out.writerow([f["asset"], cve, state, v.get("status", ""), k.get("dateAdded", ""),
                      k.get("dueDate", ""), k.get("knownRansomwareCampaignUse", ""),
                      exp or "", auto or "", ti or "", ts or "", e, pct, dexp or "", prio, step])

if __name__ == "__main__":
    main()

The test input (findings.csv) used invented assets with real CVE IDs:

asset,product,cve,exposure,human_impact
edge-mail-01,fortimail,CVE-2026-104286,open,high
k8s-node-17,linux-kernel,CVE-2026-46300,controlled,medium
build-runner-03,pkg:cargo/gix-fs@0.22.1,CVE-2026-100419,small,medium
billing-api,pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1,CVE-2021-44228,open,very high
vendor-appliance-2,pkg:generic/example-appliance@4.2,CVE-2021-44228,open,very high
legacy-scan,unknown,CVE-2026-23915,open,low

The VEX file is an invented OpenVEX document from an “Example Appliance Vendor” stating not_affected with justification vulnerable_code_not_present for CVE-2021-44228 in pkg:generic/example-appliance@4.2. We ran:

python3 patch_decision.py findings.csv known_exploited_vulnerabilities.json \
  epss_scores-2026-11-01.csv.gz deployer_patch_application_priority_1_0_0.csv \
  records/ --vex vendor.openvex.json > tickets.csv

The data came from raw.githubusercontent.com/cisagov/kev-data, the empiricalsec/epss_scores repository (2026/epss_scores-2026-11-01.csv.gz), CERTCC/SSVC (data/csv/ssvc/) and CVEProject/cvelistV5 at commit 451e97a. Output, with some columns dropped for width:

Three things in that output are worth noticing:

• The same CVE got two different answers (Log4Shell rows) because the VEX statement applies to one product only.
• A KEV-listed kernel flaw came out Scheduled. CVE-2026-46300 is in KEV with forensicTriage: Yes and a three-day federal due date, but with controlled exposure, no automatability and medium Human Impact the deployer table says Scheduled. If you follow CISA’s directives, the due date wins. If you do not, the table is telling you the exposure is what drives urgency. Either way, keep both fields in the ticket, and consider a compromise check when forensicTriage is Yes; our BOD 26-04 explainer covers what that flag asks agencies to do.
• EPSS and KEV disagreed on FortiMail, as expected: one estimates future observed activity, the other records evidence already seen.

What the ticket should hold

Store the inputs, not just the priority, so a reviewer can see why. A suggested field list (ours, not a standard):

Keeping it current

The feeds move at different speeds: CISA updates KEV on weekdays, EPSS publishes daily, and CVE records and VEX documents change when their authors revise them. Re-run the flow on a schedule and on any change to a ticket’s inputs, and alert when a finding’s priority rises. Set your service-level targets per priority (for example, how many days “Out-of-cycle” means for you) in policy, not in the script; the deployer model does not define days.

Limits of this article

The script is a working example, not a product. It reads CVE records from a local folder (it does not fetch them), does not evaluate affected versions itself (pair it with a version check such as the evaluator in our affected-versions guide), handles OpenVEX JSON only, and uses one policy choice (KEV overrides an older CISA Exploitation value) that you may want to change. The four-value deployer inputs simplify real decisions: SSVC expects organizations to adapt trees to their context. We did not test it against commercial scanner exports.

Sources and verification