A CVSS 9.8 in an unreachable test utility sits atop the backlog, while a 7.5 on an internet-facing authentication path waits below it. Risk depends on your deployment, and a score that describes the flaw cannot order your queue.
Rising disclosure volume has removed the manual slack that once absorbed that gap, making ordering risk in a flooded queue a daily operational challenge. Here is why severity-ranked triage fails on exposure, what breaks when central enrichment stalls, and how to cut a deep queue with the team you have.
Why do severity scores misorder risk when disclosure volume is this high?
Severity scores misorder risk because CVSS measures a vulnerability in the abstract, without assessing whether your code executes the flaw or whether attackers are exploiting it. At high volume, raw severity fails to distinguish active threats from dormant code, leaving teams fixing theoretical bugs while reachable flaws wait.
Severity-ranked triage became standard because it is cheap, requires no infrastructure inventory, remains stable across rescans, and satisfies compliance audits. The arithmetic in a severity score is not wrong; it is answering a different question from production risk.
CVSS base metrics assume theoretical worst-case conditions, assigning identical scores whether software faces the public internet or sits on an isolated subnet. As CISA notes in its prioritisation directives, base scores measure severity alone and cannot determine remediation. Base metrics score exploitability characteristics, not whether working exploit code exists. Yet FIRST documentation notes that only three to five percent of published CVEs ever see functional exploit code, while environmental metrics require configuration data few teams maintain.
This disconnect compounds as disclosures surge from roughly 40,000 in 2024 to 48,185 in 2025, with forecasts exceeding 66,000 for 2026. In that flood, eight-month-old alerts compete with fresh arrivals, even though FIRST data indicates that older vulnerabilities often experience exploitation rates five times higher than month-old disclosures, as vulnerability disclosure outruns the ability to patch.
Static scoring also overlooks flaw composition. Attackers chain minor defects together into severe compromises. On Snyk’s TaintedPort benchmark, scanners identified 37 of 57 individual vulnerabilities but missed all 15 exploit chains, whereas offensive security tools confirmed 10 of 15 chains across live paths. The scanners were measured on individual flaws and offensive tooling on chains, which is not a like-for-like miss rate, but it shows how component scoring misses the path. In Snyk’s open source telemetry across roughly 300,000 organisations in early 2026, 94% of findings had an available fix, but only 10% were resolved. Meanwhile, remediation research compiled by Pixee shows that across scanner findings, less than 0.1% represented genuine threats once filtered for reachability and active exploitation.
What each signal actually answers
- CVSS: How severe is the vulnerability in the abstract?
- EPSS: How likely is exploitation in the wild over the next thirty days?
- CISA KEV: Has anyone already exploited this flaw in active attacks?
- Reachability: Can an attacker actually execute this code path in your deployment?
Severity triage is auditable, but blindness to execution paths misallocates engineering effort. That ranking also depends on an input that is arriving less often.
Why does the NVD only fully analyse a fraction of new CVEs, and what breaks for defenders when it doesn’t?
Submissions to the National Vulnerability Database (NVD) rose 263% between 2020 and 2025, so NIST adopted risk-tiered analysis that leaves most findings unanalysed. Without enrichment, CVEs lack CVSS scores and Common Platform Enumeration (CPE) mappings. Scanners produce silent false negatives, automated workflows stall, and human triage absorbs the gap.
Enrichment transforms a raw advisory into actionable data by assigning CVSS metrics, references, and CPE strings. CPE data allows tools to match a CVE identifier to a specific dependency in your production environment. Without it, automated scanners cannot reliably detect the vulnerability.
As NIST stated in its operational update, rising submission volume forced it to restrict immediate analysis to vulnerabilities in CISA’s Known Exploited Vulnerabilities catalogue, software deployed by federal agencies, or applications designated under federal security directives. Everything else joined an unscheduled backlog.
According to secondary analysis from Trend Micro, the NVD fully analysed only about 28% of 2025 CVEs. By August 2026, live backlog data from Simbian showed over 78% of 2026 disclosures sitting unanalysed. An analysis by Socket explains the operational cost: without CPE enrichment, defensive tools silently miss vulnerable packages, SLA timers tied to CVSS scores never trigger, and engineers must manually investigate ambiguous alerts. The unanalysed long tail skews toward peripheral libraries favoured by adversaries.
Cloudflare, for example, addresses this bottleneck by running an internal Vulnerability Discovery and Remediation harness, validating whether reported bugs are accessible through live routes and firewall rules before generating developer tickets. For most organisations, defending systems requires consuming independent sources, including the GitHub Advisory Database (GHSA) and commercial feeds like VulnCheck. When an advisory lacks a CVSS rating, it signifies missing data rather than low severity: treat an unscored finding as an unknown, never as a low risk.
If the score is not arriving, the question stops being which critical to fix first.
How do I decide which findings to fix first when the critical queue is 300 items deep and I have twelve engineers?
Clear findings listed in the CISA Known Exploited Vulnerabilities catalogue within hours, rank the remainder using EPSS on reachable components, batch shared dependency updates, and register the rest as accepted risk. A 300-item queue is cleared by disqualification: remove the findings that are not your exposure.
Twelve engineers allocating 20% to 25% of their time to vulnerability remediation yields roughly 2.5 to 3 full-time equivalents. At one finding resolved per engineer-day, a 300-item queue represents 100 to 120 working days: a full quarter of capacity before accounting for new disclosures. As Snyk notes in its AppSec workflow analysis, when inflow outpaces resolution, reranking simply yields a tidy queue of the same unmanageable length.
Your team shrinks the queue by disqualifying findings that do not present real exposure: unreachable code paths, build-only tools, and workloads shielded by verified access controls. With non-exposed items removed, your operating rule sorts what survives into four clear bands:
Band one handles confirmed exploits in the CISA catalogue, which need containment first, in hours, because the window you are racing is now measured in hours. Band two ranks remaining reachable findings by EPSS probability to target active exploitation threats. Band three groups fixes by patch availability; as guidance from Orca Security suggests, updating a shared parent dependency or base image resolves multiple tickets in a single validation cycle. Band four moves unaddressed items onto your accepted-risk log with a named owner, compensating controls, and a review date. Our guide on turning the ordering into a budget case covers translating this capacity arithmetic for leadership.
Where the signals live, and how current they are
CISA publishes the Known Exploited Vulnerabilities catalogue, adding entries as researchers confirm active exploitation. FIRST publishes the Exploit Prediction Scoring System, recalculating 30-day exploitation probabilities daily across more than 300,000 CVEs. Both change when conditions change, but they reflect external threat activity rather than your internal architecture.
Exploitability-ranked triage has its own failure mode: EPSS measures statistical probability rather than absolute safety, and CISA reflects only confirmed public activity. Without accurate reachability data from your own estate, your team risks deferring a dangerous flaw that has simply not been noticed yet.
For governance, track band-one age rather than total open alerts. Total alert volume reflects scanner sensitivity; how long an exposed, exploitable flaw has been sitting measures true defensive posture.
Remediation must answer a question about your system, while severity answers a question about the flaw in isolation. Disqualifying unreachable code and using exploitation intelligence turns triage into a defensible operating rule, ensuring your team fixes what can actually hurt you. For a broader look at managing disclosure volume, read the cluster overview.
Frequently Asked Questions
Does a low EPSS score mean a vulnerability is safe to ignore?
No. EPSS is a probability, not a verdict, and a low score tells you exploitation is unlikely across the whole population of CVEs, not impossible in your deployment. It only becomes a decision once you add the reachability test. A flaw in an unreachable library can sit low and stay there; a flaw in an internet-facing authentication path deserves attention even at a modest score.
Can CVSS v4.0 threat and environmental metrics fix the misordering on their own?
Partly, and not reliably in practice. CVSS v4.0 adds an Exploit Maturity threat metric and environmental metrics that weight a score against your own deployment, which is the standards-level answer to context-free scoring. The difficulty is that environmental scores must be computed per finding, and doing that at volume needs inventory and exposure data most teams do not have, so it becomes a manual exercise nobody keeps current.
What is the difference between queue depth and queue age?
Depth is how many findings are open; age is how long the important ones have been sitting. Depth mostly tells you the scanners are working. Age tells you whether the team is clearing the items that matter. Report band-one age to the board, because a shrinking queue can still hide a critical that has been open for five months.
How do I defend an accept-risk decision to an auditor or the board?
Write it down as a decision rather than a gap. Each entry needs the finding, the evidence that it is not exposed (unreachable path, no internet exposure, a compensating control), a named owner, and a review date. That turns “we did not fix it” into “we assessed it and chose not to”, which is the distinction auditors and boards actually test.
What about the vulnerabilities that never get a CVE in the first place?
They are the bulk of your real exposure, and no severity feed will rank them. Misconfigurations, missing authorisation checks, exposed storage and logic flaws rarely receive a CVE, so the CVE pipeline is a partial view of your estate. Cloudflare’s Vulnerability Discovery Harness is the reference example of generating that context internally rather than waiting for an identifier to arrive.
Should I stop using CVSS altogether?
No. CVSS remains useful as an anchor and as a communication format: it is stable across rescans, understood by vendors and auditors, and required by frameworks such as PCI DSS. The mistake is using it as the only sort key. Keep it for describing the flaw, use KEV and EPSS to rank exploitation likelihood, and use reachability to decide whether the flaw is yours to fix this week.
How do I actually tell whether a vulnerable dependency is reachable?
Start with static reachability analysis from your software composition tooling: does your code call the vulnerable function, and does attacker-controlled input reach it? Then confirm with runtime evidence where you have it, such as whether the library loads in a running service. Build-only and development dependencies are the easy wins. Treat the result as evidence rather than proof, because call graph analysis produces false negatives.
Do I need to buy a vulnerability prioritisation platform to run this?
Not to start. KEV and EPSS are free, published daily or as exploitation is confirmed, and a spreadsheet plus an accept-risk register will run the four-band rule for a team of twelve. What you cannot do cheaply is reachability at scale, so that is usually the first thing worth paying for, through your existing composition tooling or a dedicated platform. Buy the exposure data before the dashboard.
How often should I re-check KEV and EPSS for items I have accepted as risk?
Continuously, because both signals move without you. EPSS is rescored daily by FIRST, and KEV grows as CISA confirms new exploitation and has gone from 1,239 to 1,484 entries. Wire an automatic promotion rule: any accepted item that lands in KEV leaves the register and enters the urgent band, with no discussion required. Review dates catch the rest.
Is KEV-first triage fast enough when exploitation happens within days?
Rarely on patching alone, which is why the first response is containment rather than a fix. For a KEV item, the question in the first hours is what reduces exposure now: taking the service off the internet, adding a WAF rule, disabling the vulnerable feature, or restricting egress. Patching follows. Clearing KEV first buys you those hours; it does not make the patch land sooner.
What if we do not have a reliable asset inventory?
Then fix that first, because every ranking above it depends on it. Reachability, internet exposure and business criticality all resolve to questions about assets you may not know you run. Start narrow: internet-facing services, anything touching customer data, and the systems the business would notice within an hour. That subset is enough to run disqualification honestly.
What counts as a compensating control when I cannot patch yet?
Anything that removes or narrows the path an attacker needs. Network segmentation, a reverse proxy rule blocking the vulnerable endpoint, disabling the affected feature, restricting outbound traffic, or alerting on the specific exploit pattern. It has to be testable and time-bound: record what it blocks, who owns it, and when it expires. A control nobody has verified is a note, not a mitigation.
