Many software teams have a vulnerability backlog in the thousands. It came from a scanner, it’s sorted by severity, and someone has been asked to “work through it.” Six months later the number is higher than when they started.

The problem isn’t effort. It’s that a backlog sorted by severity treats every finding as equally likely to hurt you, and almost none of them are.

Why lists fail

Severity scores describe a vulnerability in isolation. They don’t know whether the affected service is reachable from the internet, whether the vulnerable function is ever called, or whether the data behind it matters.

So a critical library flaw in an internal batch job sits above a medium authorization bug on your public API. The first is noisy and hard to exploit. The second is how customer data leaks.

A backlog is a map of possibilities. Your job is to find the few that are real paths.

2026 made this harder

The volume has changed faster than most teams’ processes. Jerry Gamblin’s mid-year review counted 35,364 CVEs published in the first half of 2026, up 49.5% on the same period of 2025. Almost half of them, 49.1%, were rated critical or high.

Exploitation hasn’t kept pace. Of those 35,364, only 85 had been added to CISA’s Known Exploited Vulnerabilities (KEV) catalog by the end of June: 0.24%. Gamblin calls that figure “a floor, not a verdict”, because exploitation is often confirmed months later. Even so, if half your new findings are critical or high and well under one percent are known to be exploited, severity can’t be what decides your sprint.

The scores themselves are also thinner. On 15 April, NIST announced that the National Vulnerability Database would stop routinely enriching CVEs published before 1 March 2026 and would prioritise vulnerabilities in KEV, in software the US federal government uses, and in critical software. Records outside those criteria are now marked “Not Scheduled”, and NVD will generally stop adding its own CVSS score where the reporting organisation has already supplied one. If your tooling reads severity from NVD, expect more findings with a vendor score, a different score or no score at all.

Three questions that reorder everything

Before a finding earns engineering time, ask three questions about it:

  1. Can an attacker reach it? Is the component exposed, directly or through another service?
  2. Can they actually exploit it? Is the vulnerable code path used, and are the preconditions realistic?
  3. What would it cost you? What data, money or trust sits behind it?

Findings that pass all three go to the top, whatever their score. Findings that fail the first question usually drop to a scheduled patch cycle.

Two public signals help with the second question. KEV tells you a vulnerability has been exploited in the wild. EPSS, published daily by FIRST, estimates the probability that a CVE will see exploitation activity in the next 30 days. Neither knows your environment, so neither replaces reachability. They’re a better tiebreaker than CVSS alone.

A useful rule of thumbIf you can’t describe the attack in one sentence, including where it starts, you don’t yet know whether the finding matters.

What this looks like in practice

Consider an illustrative case. A scanner reports around four hundred issues. After checking reachability and exploitability, only a handful need action this sprint, and some of those are rated medium by the scanner. A missing ownership check that exposes order history across accounts is a typical example.

The rest aren’t ignored. Dependency updates are batched into a monthly patch window, and configuration issues go into the platform team’s normal queue. Anything that appears in KEV jumps the queue the day it’s added, if the affected component is reachable.

What to do this week

  • Tag every asset in your inventory as internet-facing or internal.
  • Filter your backlog to internet-facing assets first, then sort by severity.
  • Add two columns: “in KEV” and the current EPSS score. Both are free to download.
  • For the top twenty, write the one-sentence attack. Discard the ones you can’t.
  • Batch the remaining dependency updates into a regular patch cycle.

You’ll end the week with a short list your engineers believe in, and that’s worth more than a long list nobody reads.

Sources

  1. Jerry Gamblin: CVE mid-year 2026 check-in (1 Jul 2026) (opens in a new tab)
  2. Infosecurity Magazine: NIST drops NVD enrichment for pre-March 2026 vulnerabilities (16 Apr 2026) (opens in a new tab)
  3. CISA: Known Exploited Vulnerabilities catalog (opens in a new tab)
  4. FIRST: Exploit Prediction Scoring System (EPSS) (opens in a new tab)