From Scanner Export to Patch List: A CVE Triage Workflow

A vulnerability scan finishes and leaves you holding a list. Sixty CVE IDs, sometimes six hundred, each tagged with a severity the scanner pulled from its own feed. The list arrives sorted by that severity, because severity is the only thing the scanner knows about. Somewhere in it are the two or three vulnerabilities an attacker is actively using this month, and nothing in the sort order points at them.

The scores themselves are a subject of their own, and we cover them in CVSS, EPSS and KEV explained. This is the other half: the unglamorous sequence of steps that turns an export into a list somebody will actually work through on Monday.

What the scanner handed you#

Scanner output is a report, not a plan. It tells you what it found and how bad each finding would be if someone exploited it. It does not know whether anyone is exploiting it, whether the affected host is reachable from the internet, or what your change window looks like.

Two of those gaps only you can close. The exploitation gap is different, because the evidence is public, and closing it is what makes re-sorting the list worthwhile.

Start by noticing what the delivered sort actually gives you. In CVSS v3.1 the Critical band runs from 9.0 to 10.0, and a large estate can return a great many findings sitting inside it. Everything in that band is ranked equal. That is a tie rather than a priority order, and the scanner has no way to break it.

Getting the IDs out of the export#

Exports arrive in whatever shape the tool that made them felt like. A CSV column, a PDF table, a block pasted into a ticket, an advisory email with the IDs scattered through the prose. Cleaning that up by hand before you can start is the tax that stops most people from re-triaging at all.

The better move is to stop cleaning and start pattern-matching. Our bulk CVE triage tool takes arbitrary pasted text and pulls the CVE IDs out of it, uppercased and de-duplicated, in the order they first appear. Paste the whole mess and let the pattern do the filtering.

There is a trap in writing that pattern yourself, and it fails silently. The obvious expression is CVE-\d{4}-\d{4}: the literal prefix, a four-digit year, a four-digit sequence number. The sequence number is not fixed at four digits, and it has not been for years.

The scale of that is easy to measure against real data. Of the 1,710 vulnerabilities in CISA's Known Exploited Vulnerabilities catalog as of mid-September 2026, 1,006 carry a sequence number longer than four digits. Five-digit IDs alone account for 999 of them, and a handful run to seven. A four-digit pattern does not error on those. It just matches nothing and moves on, and your triage list comes back missing the majority of the catalog's entries. Match four digits or more.

De-duplication matters for a different reason. Scanners report the same CVE once per affected host, so a long export can collapse to a much shorter list of distinct vulnerabilities. The repeat count tells you how widely exposed you are, which is useful, but it is a different question from what to patch first. Collapse the list to distinct IDs before ranking it.

The three signals, in one pass#

Three public sources answer three different questions about a vulnerability:

• KEV asks is someone exploiting this right now? CISA's catalog is a binary membership test, published under CC0.
• EPSS asks how likely is exploitation soon? FIRST publishes a probability that a vulnerability will be exploited in the wild within the next 30 days, with new scores each day.
• CVSS asks how bad would it be if it happened? A severity, fixed at publication.

Collecting all three for a long list sounds expensive and is not. Enriching a batch costs two upstream calls in total, regardless of how many IDs are in it: one to NVD for descriptions and CVSS, one to EPSS for the whole batch at once. KEV membership needs no network call at all, because the catalog is small enough to read from a local snapshot. The cost does not scale with your list, which is precisely why triaging the whole export is practical rather than something you do for the top ten.

Ranking by evidence instead of dread#

Sorting by CVSS is the default nearly everywhere, and it is the wrong first key. A 9.8 that nobody has ever attacked will outrank a 7.5 with a working exploit in circulation, every time, and that is how patch queues end up ordered by dread rather than by evidence.

FIRST says as much about its own metric. Section 2.1 of the CVSS v3.1 User Guide is titled "CVSS Measures Severity, not Risk", and states that the Base Score should not be used alone to assess risk, because a comprehensive assessment considers more factors than the Base Score alone.

So invert the keys. Confirmed exploitation first, probability of exploitation second, severity only as a tie-breaker. That produces five tiers:

• Exploited: listed in KEV. Exploitation is confirmed, not predicted.
• Likely: not in KEV, but EPSS puts exploitation in the next 30 days at 10% or higher.
• Elevated: EPSS at 1% or higher, meaningfully above the background rate, where most CVEs sit.
• Low signal: scored, but with no current exploitation signal.
• No data: nothing published to prioritise on.

The 10% and 1% cut points are judgement calls rather than anything FIRST defines, which is why the tool states them on the page instead of burying them. Inside the Exploited tier the order goes ransomware-linked entries first, then the earliest CISA remediation date.

One thing the ranking deliberately refuses to do is blend the three into a single composite score. Mixing a binary catalog, a probability and a severity produces a number with no units that nobody can argue with. Every row instead carries the specific evidence that placed it, written out, so you can disagree with a placement for a stated reason.

What each tier means on Monday morning#

The tiers are only useful if they map onto things your change process can actually do.

Exploited is an emergency change. These are being used against real targets now. The ransomware flag sharpens it further: 360 of those 1,710 KEV entries are linked to known ransomware campaigns, and a ransomware-linked entry on an internet-facing host is the strongest argument for an out-of-hours window you will ever get from public data.

KEV entries also carry a remediation due date, which is the deadline CISA sets for US federal agencies under the binding operational directive the catalog currently cites, BOD 26-04. That deadline is not binding on a private company. It is still a useful external calibration of how urgent the government considers the same vulnerability, and a due date already in the past is a strong signal.

Likely belongs in the current sprint. Elevated goes into the normal schedule with a note. Low signal rides the routine patch cycle. None of those need a meeting.

The rows a severity sort would have promoted#

The rows that move furthest down are the ones with high CVSS scores, 9.0 and above, and no exploitation signal behind them. The triage tool surfaces these separately, because they are exactly the rows the delivered sort put at the top of your list.

This is not an argument for ignoring them. A high base score with no current exploitation is still a weakness, and EPSS is a forecast that can change tomorrow. It is an argument about sequence. When two things compete for the same maintenance window, the one with confirmed exploitation wins, and this list shows you what you were previously choosing instead.

The rows with nothing to go on#

Some rows come back with no severity and no probability. Recently published CVEs can sit in NVD's enrichment queue unscored, and a vulnerability with no published EPSS score has no forecast attached either.

How a tool renders that gap matters more than it sounds. A blank cell or a 0.0 reads as "harmless" at a glance, which is the opposite of what is true. An unscored row says CVSS not scored yet and lands in its own tier, where the honest instruction is to judge it on your own exposure and the vendor's advisory rather than on a number nobody has assigned.

For any single ID you want to examine on its own, the CVE explorer gives you the NVD description and CVSS alongside KEV status, the federal remediation date and the ransomware flag. Note that the single-lookup view deliberately leaves EPSS out; the probability arrives with the bulk triage path, not this one.

Lists longer than a hundred#

The triage tool takes up to 100 distinct CVE IDs per run. Longer exports split cleanly into batches, and because the ranking is deterministic you can merge the results afterwards without the tiers disagreeing across batches.

The more commonly missed step is re-running it. EPSS republishes every score daily, and CISA adds to KEV on its own cadence, so a triage you ran three weeks ago is describing a threat picture that has since moved. A vulnerability can enter KEV long after your scan found it, which promotes it from the bottom of your list to the top without anything about your estate changing. Re-run the same list before each patch window and compare the tiers; that diff is usually a shorter and more interesting read than the original ranking.

What the ranking cannot decide for you#

Every signal in this workflow describes the vulnerability. None of them describes your environment. That is the limit to be explicit about.

Public evidence cannot see whether the affected service is internet-facing or sitting on an isolated management network, whether a compensating control already blocks the attack path, or whether the host in question runs payroll or a lab printer. A KEV entry on an unreachable internal system may rank below an Elevated finding on your public edge. That judgement is yours, and it is the step where knowing your own asset inventory beats any public feed.

What the workflow does is put the rows in front of you in an order built on evidence, each one carrying the reason it landed where it did. You still decide what to patch. You are just no longer deciding it from a list sorted by how frightening each entry sounds.