[ SOC.3 — BULK CVE TRIAGE ]

Sixty CVEs.
Which first?

A scan hands you a list; the only question that matters is the order you work through it. This checks every ID against three signals that answer three different questions — is it being exploited now, how likely is it to be, and how bad would it be — then sorts by the first two rather than the third.

Corrections welcome — see our editorial policy.

0 / 100
IDs are picked out of whatever you paste, so a scanner report works as-is — no cleanup needed. Duplicates are collapsed. Maximum 100 per run.

Why this order, and not CVSS

Most vulnerability lists arrive sorted by CVSS, and that is the wrong first key. CVSS answers “how bad would this be if someone exploited it” — a question about consequences, not about likelihood. Sorting by it puts a 9.8 nobody has ever attacked above a 7.5 with a working exploit in the wild.

FIRST, who own CVSS, say so themselves: the base score measures severity and should not be used alone to assess risk. So this tool sorts by evidence first and severity last:

  1. CISA KEV — is it in the Known Exploited Vulnerabilities catalog? That is not a prediction. It means exploitation has been observed. Everything in this tier goes above everything else.
  2. EPSS — FIRST's estimate of the probability that a CVE will be exploited in the next 30 days. It is the best available answer to “is this about to matter”.
  3. CVSS — how severe it would be. Shown on every row, used only to break ties.

There is deliberately no blended “risk score”. Averaging a catalogue, a probability and a severity into one number produces something with no units that nobody can argue with. Every row here instead carries the specific evidence that placed it, in words, so you can disagree with the ranking for a stated reason.

Reading the result

Exploited means the CVE is in CISA's catalog. The remediation dates CISA attaches are binding on US federal civilian agencies; if that is not you, treat them as a strong hint about urgency rather than a deadline you have missed.

Likely and Elevated are EPSS bands — at or above 10%, and at or above 1%, probability of exploitation in the next 30 days. Those cut-offs are a judgement call, stated here rather than hidden: most CVEs sit far below 1%, so 1% is already meaningfully above the background rate.

No data is its own tier, and it is not the same as low risk. It means the CVE is not in KEV and has no published EPSS score, so there is no exploitation signal in either direction. Judge those on severity and your own exposure.

What this cannot tell you

  • KEV is a US federal catalogue. Absence from it is not evidence that something is not being exploited — only that CISA has not added it.
  • EPSS is a probability, not a severity. A low EPSS on a critical bug in an internet-facing system is not permission to ignore it.
  • Some CVEs have no CVSS at all. NVD's enrichment has run behind since 2024, so recent IDs may show “not scored yet”. That is a gap in the data, not a score of zero.
  • None of this knows your environment. A wormable bug in software you do not run outranks nothing. Exposure, reachability and compensating controls are yours to add.

Common scenarios

“The scanner returned 200 findings.”

Paste the report in batches of 100 — the IDs are extracted automatically, so the surrounding table formatting does not matter. Work the Exploited tier first, then Likely. In most real scan output those two tiers are a small fraction of the total, which is the point.

“Everything came back critical.”

That is what a CVSS-sorted list looks like. Check the summary line for how many are actually in KEV; a long list of 9.8s with no exploitation signal is a backlog, not an incident.

“I need to justify the patch order to someone.”

Each row states its reason in words — catalog membership with dates, or an EPSS probability with its percentile. Export the CSV and the reasoning travels with the list.

Related tools

Copied!