A vulnerability backlog is an inventory management problem: every open finding has an acquisition cost (triage), a carrying cost (risk plus re-triage), and a disposal cost (the fix) — and most programs go bankrupt because they pay triage costs on findings whose expected risk is lower than the cost of reading them. Once you frame it as economics instead of hygiene, the standard advice ("fix all criticals in 15 days") starts looking like the money-loser it usually is.
The arithmetic nobody runs
Take an unremarkable mid-size engineering org: 300 repositories, scanned by an SCA tool, producing 8,000 open findings. The flow numbers matter more than the stock:
- New findings arrive at maybe 150–400/week — over 40,000 CVEs were published in 2024 alone, and each new disclosure fans out across every repo containing the affected package.
- Triage costs 5–20 minutes per finding when done honestly (identify the app, check the version, decide exploitability, route it). Call it 12 minutes average.
- Fix costs range from 10 minutes (clean patch bump, tests pass) to multiple days (major-version migration with breaking API changes).
Triage alone on 300 findings a week is 60 engineer-hours — one and a half full-time engineers doing nothing but reading scanner output. At a loaded cost of $120/hour, that's about $375k/year before anyone fixes anything. This is why backlogs grow: the input rate exceeds the funded processing rate, and the gap compounds. A backlog that grows by 50 findings a week is 2,600 deeper by next year, and every one of those will eventually be re-triaged when someone asks "is this still relevant?"
Carrying cost is real but wildly uneven
The naive model says every open critical is a smoldering fire. The empirical data says otherwise: across the published exploitation research (Cyentia/Kenna's long-running series, FIRST's EPSS validation work), roughly 5% of CVEs are ever exploited in the wild. The carrying cost of the other 95% is approximately zero risk — but not zero cost, because they clog dashboards, trigger SLA breaches, consume re-triage cycles, and show up in customer security questionnaires.
This unevenness is the entire case for risk-based prioritization:
| Strategy | Effort (share of CVEs remediated) | Coverage of actually-exploited CVEs |
|---|---|---|
| Fix all CVSS 7.0+ | ~58% of all CVEs | good coverage, catastrophic efficiency |
| Fix CISA KEV entries | ~1,400 CVEs total | near-perfect precision, incomplete recall |
| Fix EPSS above 0.1 | roughly 5–10% of CVEs | captures the large majority of exploitation at a tenth of the effort |
CVSS-driven remediation is the expensive option dressed up as the rigorous one. More than half of all CVEs score High or Critical, so "fix all highs" is barely a filter — it's a commitment to remediate most of the ecosystem's output forever. EPSS-driven queues deliver several times the risk reduction per engineer-hour; the FIRST data puts the efficiency gain at roughly 5–7x over CVSS thresholds.
Reachability analysis compounds this again. In dependency findings specifically, most vulnerable functions are never called by the application — typical reachability studies land between 10% and 30% reachable. An SCA pipeline that does reachability-aware prioritization is buying you a 70–90% reduction in the queue before a human reads anything.
Where the money actually goes: fix cost curves
Fix cost isn't constant across the backlog; it's bimodal, and the shape dictates strategy.
Cheap fixes cluster. Patch and minor bumps with passing tests are 10–30 minutes each, and they batch: upgrading jackson-databind once in a shared parent POM can close 40 findings across 25 services. Batch-fixing by package rather than by finding routinely closes 30–50% of a dependency backlog in a sprint. Automated PR generation (Renovate, Dependabot, or your platform's remediation engine) drops the marginal cost to review-only.
Expensive fixes are where backlogs calcify. The Spring 4 to 6 migration, the Node 14 app pinned by a native module, the vendored copy of a library nobody remembers importing. These are engineering projects wearing vulnerability costumes, and pretending a 15-day SLA applies to them just trains everyone to ignore SLAs. Price them honestly — as projects — and make an explicit accept/fix/replace decision with a date. Undecided is the most expensive state, because you keep paying re-triage on it forever.
The economic insight: age is not severity. A 400-day-old finding in an unreachable code path costs you nothing but dashboard shame. A 3-day-old KEV entry on an internet-facing service is the house fire. Programs that report "mean age of open findings" as their headline metric optimize for closing cheap trash, not reducing risk.
Metrics that reflect the economics
If you want the backlog managed like inventory, measure it like inventory:
- Arrival vs. closure rate, weekly. If closure is below arrival, no SLA policy matters — you're insolvent, just slowly.
- Exploitable-open count: findings that are KEV-listed or EPSS above 0.1 and reachable and on a deployed service. This should be a small number with an on-call-grade response, not a spreadsheet.
- Cost per closed finding, tracked by fix type. This tells you where automation pays: if 60% of closures are clean patch bumps, auto-merge policies for patch-level security updates are your highest-ROI investment.
- Accepted-risk register size and review age. Acceptance is a legitimate disposal channel; unreviewed acceptance is deferred triage debt.
One number worth publishing internally: findings auto-closed by upgrades that happened for other reasons. In healthy orgs with fast dependency-update automation, 40–60% of dependency findings are closed as a side effect of routine bumps that nobody triaged individually. That's the cheapest remediation in existence, and it's an argument for funding update automation before funding more triage. The follow-on discipline — keeping debt from re-accumulating — is a topic of its own; see security debt: measuring and paying it down.
Frequently asked questions
What's a healthy vulnerability backlog size?
Size alone is the wrong metric — 8,000 open low-EPSS, unreachable findings can be healthier than 40 open KEV-listed ones. Health means: exploitable-open count near zero, closure rate at or above arrival rate, and every finding older than 90 days carrying an explicit fix/accept decision rather than silence.
Should we just declare backlog bankruptcy and close old findings?
A one-time bulk closure of stale, low-risk findings is defensible if you do it with criteria (below EPSS 0.05, not in KEV, unreachable, or in decommissioned services) and an audit note — mass-closing without criteria destroys the dataset your metrics depend on. Fix the arrival-rate problem first, or the backlog regrows to its old shape within two quarters.
Is EPSS reliable enough to deprioritize criticals?
EPSS is a probability estimate, not a guarantee, but the validation data consistently shows it dominates CVSS as an exploitation predictor, and it re-scores daily as evidence changes. The defensible posture is EPSS plus KEV plus reachability plus asset exposure — deprioritizing a CVSS 9.8 that fails all four tests is risk management, not negligence, and platforms like Safeguard compute that intersection automatically so the queue reflects it.
How do we justify remediation headcount to leadership?
Present the flow economics: arrival rate, triage cost per finding, and the gap between funded capacity and input. "We receive 300 findings weekly, honest triage costs 60 hours, and we've funded 20" is a budget conversation executives understand — far better than a count of open criticals, which reads as either scary noise or someone else's negligence depending on the quarter. Our pricing page exists because this math is usually cheaper to automate than to staff.