Stop Patching by CVSS Alone: A Three-Signal Triage Formula That Fits on a Sticky Note

9/26/2026

Somewhere right now, a small IT team is staring at a vulnerability scan with four hundred findings, sorted by CVSS score, trying to decide what to actually do this week. They'll patch some 9.8s that nobody on earth is exploiting, run out of change-window, and leave untouched a 7.2 that ransomware crews have been using for a month. Not because they're careless, but because severity is the only column their tooling put in front of them.

CVSS was never designed to be a patch queue. It measures how bad a vulnerability could be under worst-case assumptions, not whether anyone is using it. Roughly one in twenty CVEs is ever exploited in the wild; a severity-sorted list treats the other nineteen as equally urgent. The good news is that the two missing signals are free, public, and machine-readable.

The three signals

CVSS: how bad, if it happens. Keep it, it's genuinely useful. Just demote it from the answer to one input.

EPSS: how likely it happens. The Exploit Prediction Scoring System, from FIRST.org, gives every CVE a daily probability of exploitation in the next 30 days, learned from real exploitation telemetry. It's a percentage, updated every day, fetchable from a free API. An EPSS of 0.9 means "start now"; an EPSS of 0.001 attached to a scary CVSS 9.1 means the sticker is scarier than the threat.

KEV: it's already happening. CISA's Known Exploited Vulnerabilities catalog is the shortlist of CVEs with confirmed exploitation in the wild, each with a required remediation action and a due date. US federal agencies are legally bound to it. For everyone else it's a gift: someone with better telemetry than you maintains a list titled, in effect, attackers are using these right now.

The formula

The triage rule I use (the same one my Security Feeds page computes automatically) fits on a sticky note:

  1. On KEV? Drop everything queue. It's not a prediction; it's a fact. Patch within the CISA due date or have a written reason why not.
  2. CVSS ≥ 9, or EPSS ≥ 50%? Treat as critical: this window, not this quarter.
  3. CVSS ≥ 7, or EPSS ≥ 10%? High: schedule it this cycle.
  4. Everything else rides the normal maintenance train.

Notice what the or does: a mediocre-severity vuln with high exploitation probability outranks a spectacular-severity vuln that nobody weaponised. That single inversion is most of the value, and it's exactly what pure CVSS sorting gets wrong.

Is the formula crude? Absolutely: it ignores your asset criticality, exposure, compensating controls, all the things a mature vulnerability-management program layers on. But crude-and-followed beats sophisticated-and-ignored, and a small team can run this with a spreadsheet and two API calls. It's a floor, not a ceiling.

Why this matters beyond the patch queue

Here's the GRC angle that made me care enough to automate it. When an auditor (or your board, or a regulator after an incident) asks "why hadn't you patched X?", "we hadn't gotten to it" is a bad answer, but so is "it was CVSS 6.5" if X was on KEV for ninety days. The three-signal formula gives you the thing compliance actually wants and security rarely provides: a defensible, written prioritisation rationale. Every decision traces to public, timestamped data. We patch KEV within the federal deadline; we patch predicted-exploitation above 10% within a sprint; here's the log. That sentence has ended more audit findings than any tool purchase.

It also changes the internal conversation. "Please patch this, it's severe" loses to the ops team's backlog every time. "This one is on the same list the US government mandates fixing in three weeks, and here's the exploitation probability curve." That wins change-approval meetings.

Doing it tomorrow morning

Both signals bolt onto whatever you already have. Export your scanner's findings, join against the KEV catalog (one JSON file) and the EPSS API (one GET request per batch of CVEs), and re-sort. That's the entire integration. If you want to watch the signals move without building anything, the feeds page on this site shows KEV arrivals and EPSS-scored CVEs daily, with the formula applied in public.

The uncomfortable question to ask of your current process: if a CVE landed on KEV today, how many days until your patch queue knows? If the honest answer is "whenever the next quarterly scan runs," that's the gap, and it's free to close.