Vulnerability Management at Scale: When 60,000 CVEs Per Year Breaks Your Triage Model

Mar 31

9 min read

Episode 8 of the CAXA Technologies Security Operations Series

FIRST is forecasting a median of 59,427 CVEs for 2026, with a 90% confidence interval that reaches 117,673 at the upper bound. If your current vulnerability management process requires a human to review each inbound finding, you do not have a triage model. You have a queue that will never clear.

This is not an attack on the teams operating those programmes. The volume problem is structural and it has been building for years. In 2024, roughly 40,000 CVEs were published. The 2026 projection represents a 50% increase on that baseline, and FIRST's three-year outlook suggests the upper bound reaches approximately 193,000 by 2028. The forecast is not an anomaly to plan around. It is the design constraint that vulnerability management at scale has to solve.

Episode 6 established the multi-signal prioritisation model: CVSS base score as a severity anchor, EPSS as the exploitation likelihood signal, KEV as the binary confirmation of active exploitation, and SSVC as the structured decision framework for edge cases. That model is the right prioritisation approach. What it does not address is the operational model question: what does the process look like when the inbound volume exceeds the capacity of any team to review findings one at a time?

That is what this episode covers.

The queue-based model breaks before you notice it is breaking

Most vulnerability management programmes operate on a variant of the same process: scanner runs, findings are ingested, a team triages the output, critical and high findings are ticketed, and the remainder go into a backlog. At lower volumes, this works well enough. The signal-to-noise problem is real but manageable. Teams develop intuition for the patterns in the output.

At 60,000 CVEs per year, roughly 1,150 per week, the queue-based model does not fail dramatically. It degrades quietly. Review cycles get longer. The backlog grows faster than it clears. The critical segment gets attention because it has to; the high and medium populations accumulate. MTTR climbs. The team starts to feel like they are always behind, because they are.

The failure mode is invisible in the metrics that most programmes measure. Open vulnerability count goes up, which looks alarming. Remediation rate stays roughly constant, which looks like the programme is working. The combination produces a growing backlog that the measurement model misrepresents as stable performance. I have seen this pattern in several large-scale environments: the programme is not broken, but the process is running near its capacity ceiling without anyone having explicitly decided that is acceptable.

The answer is not to add headcount. The answer is to stop treating triage as a human task at the input stage.

Exception-based review, not queue-based review

The inversion that high-volume programmes need is straightforward to describe and genuinely difficult to implement: automated scoring and classification should handle the majority of findings, with humans reviewing threshold breaches, escalation triggers, and exception requests, not the queue itself.

This is exception-based review. The human is not the first filter; they are the last one.

What the automated layer does:

Applies the multi-signal scoring model to every inbound finding. EPSS score, CVSS base, KEV status, and asset tier each contribute to a composite risk score.
Assigns a disposition based on defined thresholds: auto-ticket for findings above the threshold, log-and-monitor for findings below it, and mandatory-action for any KEV entry regardless of score.
Creates tickets in the remediation workflow with SLA already assigned, ownership already mapped, and context already attached: scanner output, asset tier, EPSS score, KEV status.

What the human does:

Reviews escalation triggers: SLA breach imminent, exception request submitted, new KEV entry matching an asset in scope.
Evaluates exception requests: the escalation and risk acceptance approach Episode 4 described, applied to findings that owners cannot remediate within SLA.
Runs the metrics review: MTTR trend, SLA compliance rate, KEV exposure. The measurement framework Episode 5 described, at the frequency the programme requires.
Makes judgement calls on threshold anomalies: an EPSS score that has moved significantly since the finding was logged, an asset tier reclassification that changes the risk profile of existing open findings.

The triage queue does not disappear. It becomes the exception channel, not the primary channel.

KEV is not a prioritisation signal, it is a hard floor

This distinction matters more at scale than it does at lower volumes. When the inbound rate is high and the automated scoring model is carrying most of the triage load, KEV entries need special handling.

A finding in Known Exploited Vulnerabilities catalogues represents confirmed active exploitation in the wild. The CISA KEV catalogue reached 1,484 entries by the end of 2025, with 245 added in 2025 alone, a 20% year-on-year growth rate. That catalogue is not a prioritisation input. It is a bypass trigger.

Any finding that matches a KEV entry should bypass the composite scoring model and trigger a mandatory remediation action on a defined SLA, regardless of the CVSS base score, regardless of the EPSS probability, regardless of what the asset tier suggests. KEV is not a relative signal. It is a binary confirmation that this vulnerability is being used to attack systems right now. The response to that confirmation should not depend on how it scores against other findings.

The practical implementation: your SIEM or vulnerability intelligence platform holds the current KEV catalogue. Every new finding ingested is checked against it. KEV matches skip the triage queue entirely and create a high-priority ticket with a defined remediation deadline. The scoring model runs in parallel but does not influence the KEV-matched SLA.

KEV is also not an early-warning signal. Flashpoint's 2025 vulnerability research found that 28.96% of KEV entries were added on or before the CVE's public disclosure day, up from 23.6% in 2024. That sounds like KEV is getting faster. The implication is the opposite: in nearly 30% of cases, CISA is confirming exploitation that was already underway before the vulnerability was even publicly named. For the remaining 70%, the lag between exploitation beginning and KEV addition ranges from days to months. A programme that waits for KEV confirmation before acting on a finding is behind the attacker timeline in either case. The right model is continuous scanning and scoring: KEV confirmation accelerates action on an already-known finding, it does not create the finding.

The composite score, and where to set the threshold

Episode 6 established why CVSS alone produces the wrong remediation queue. The composite model, weighting CVSS as a severity anchor, EPSS as the exploitation likelihood signal, and KEV as the hard floor, is the operational baseline for any programme running at significant volume.

The specific weighting that is gaining traction in practice combines normalised CVSS score, EPSS probability, and a KEV flag. The precise weights matter less than the principle: severity and exploitability should have roughly equal influence, and KEV should function as an override rather than an incremental score adjustment.

EPSS score distribution gives a useful anchor for threshold-setting. The median EPSS score sits well below 0.01: the vast majority of published CVEs have a very low estimated probability of exploitation within 30 days. A score of 0.10 sits at approximately the 88th percentile, meaning only about 12% of CVEs score above it. According to FIRST EPSS telemetry, only around 5% of published CVEs are ever observed to be exploited in the wild.

This distribution is the basis for deprioritisation, not just for prioritisation. A non-KEV finding with a CVSS base score of 7.5 and an EPSS score of 0.02 is a different risk proposition from the same CVSS score with an EPSS of 0.35. The scoring model separates them. The threshold model decides which gets a ticket this week and which gets logged and monitored.

Setting the threshold requires validation against your own exposure history. What EPSS scores did CVEs carry at publication time, for vulnerabilities that later appeared in KEV? That distribution tells you where your deprioritisation threshold should sit: any threshold that would have missed those CVEs is too aggressive.

The asset inventory dependency is still the actual bottleneck

Most programmes that attempt to implement this model are not blocked by the scoring algorithm. They are blocked by the asset inventory.

EPSS-weighted prioritisation with asset tier context is the right model. A critical vulnerability in a Tier 1 payment processing system is a different risk from the same vulnerability in a Tier 3 development sandbox. The composite score should reflect that difference. To do that, the model needs to know which tier each affected asset belongs to.

Incomplete CMDB means the model cannot classify findings accurately. The common fallback, treating unclassified assets as Tier 1 to be conservative, generates noise. The alternative fallback, treating them as Tier 3 to reduce ticket volume, generates risk. Neither is the right answer; accurate classification is the right answer.

Episode 7 established that cloud asset inventory degrades the moment it is not fed continuously from the cloud control plane. Ephemeral workloads, container image tags, and auto-scaling groups are not tracked reliably by static CMDB processes. The CSPM platform is the authoritative asset source for cloud estates: it maintains continuous discovery from the cloud API layer, not from agent-based point-in-time scans.

At scale, CSPM is not an optional enhancement. It is the mechanism that keeps the asset inventory current enough for the scoring model to work reliably. A programme that has done the prioritisation model work but not the asset inventory work will find that the model produces inconsistent output because the context it relies on is unreliable.

The sequence matters: asset inventory accuracy first, then scoring model refinement. Not the other way around.

SCA output is a data feed, not an action queue

Software composition analysis tooling in CI/CD pipelines produces findings at a different rate from network or host scanning. A large codebase with active development may generate thousands of SCA findings per pipeline run: new library versions, transitive dependencies, and re-evaluated existing findings as EPSS scores update.

Treating each SCA finding as a discrete action item is operationally impossible at this scale. The model that works is treating SCA output as a structured data feed. The findings enter the vulnerability intelligence platform with full context, library name, version, affected service, SBOM hash, the prioritisation model is applied, and tickets are created only for findings that breach the defined threshold. Below-threshold findings are logged and reassessed when their EPSS score changes or when they appear in KEV.

This means your CI/CD pipeline does not block on most SCA findings. It produces a scored, classified finding set that feeds the same prioritisation workflow as your network scanning output. The programme's response to SCA findings is determined by the same model as its response to CVEs from any other source: severity, exploitability, asset context.

The blocking gate question belongs to Episode 9, which addresses the CI/CD pipeline as an attack surface in its own right. That is a different problem from the volume management question this episode covers.

Where this breaks

Three failure modes to name explicitly.

Threshold decay. Automated deprioritisation means findings below the threshold are not actioned: they are logged and monitored. If the threshold is set correctly at programme inception but never reviewed, it will drift out of calibration as the threat landscape changes. EPSS score distributions shift as the model updates. KEV growth changes the baseline. The threshold needs a defined review cadence; without it, the automated layer is making deprioritisation decisions based on stale calibration.

CMDB rot. Cloud asset inventory degrades without continuous feed from the cloud control plane. A stale CMDB means the tier-weighted scoring model runs on incorrect context. The highest-risk finding is not the one with the highest EPSS score: it is the one that was misclassified as Tier 3 because the asset had been reclassified in the cloud console but not propagated to the CMDB. This failure mode is invisible until an incident exposes it.

Scanner coverage gaps at scale. At higher vulnerability volumes, scanner infrastructure tuned for a lower-volume environment will lag. Scan frequency drops, coverage narrows, and asset discovery intervals lengthen. The MTTR clock starts at detection: missed assets have an infinite detection window. Coverage degradation at scale is the silent failure that makes every other metric look better than it is: if assets are not scanned, they produce no findings, and the remediation rate appears healthy while the actual exposure grows.

The 60,000 CVE forecast is not an argument for a larger team. It is an argument for an operational model that was designed for this volume. The prioritisation frameworks established in Episode 6 tell you which vulnerabilities matter. The operational model described here is how you act on that knowledge when the inbound rate exceeds what any team can manually review.

The asset inventory is where to start. Before tuning the scoring model, before deploying automated triage, before adjusting SLA thresholds: know what you have, know which tier each asset belongs to, and make sure that classification is fed continuously from the source of truth. Everything else scales on top of that foundation.

Episode 9 will cover the CI/CD pipeline as an attack surface: a problem that starts with the same question (what do we depend on, is it scanned, do we have SLAs for it?) but requires a different answer.