You are holding a queue that grew again this quarter despite record closure counts. It is an uncomfortable place to sit, because the instinct is to wonder whether your engineering team is failing. Industry data shows discovery capacity has outrun absorption capacity, creating the structural backlog problem that so many software organisations now face.
Making sense of an unclearable backlog comes down to a connected sequence of choices: diagnosis reveals which operational failure you have, the discovery-versus-validation asymmetry directs your investment, build-versus-buy produces the practical capability, and the board conversation translates the technical reality into business risk.
Most teams invert this sequence. They buy detection tooling first, only to discover they cannot absorb what it returns.
How should a 200-person SaaS company assess whether its patch queue is genuinely broken or just noisy?
Measure four things before deciding anything:
- Weekly inflow against verified closure
- Age distribution across open items
- Share of the queue that is KEV-listed or EPSS-high in reachable components
- Duplicate or non-actionable rate on intake
If band-one items (KEV-listed, reachable in code you ship) still close within agreed service-level agreements (SLAs), the queue is noisy. If they slip, it is broken and capacity-bound.
Queue depth is the number most dashboards surface, and it is the one that tells you least. Across more than 10,000 organisations, closed CISA KEV events grew 6.5 times between 2022 and 2025, yet the percentage of priority items still open past day seven climbed from 56% to 63%. A growing backlog usually means inflow is outrunning outflow.
Use this decision rule to classify your queue:
- Noisy queue: Closure trails inflow mainly on low-signal findings while reachable items close within SLA. The issue is ordering and intake, not developer headcount.
- Broken queue: Closure trails inflow on reachable, CISA KEV-listed items. This is a capacity failure that reorganising tickets will not solve.
- Unpatchable residue: Closure stalls because items have no upstream remediation path, including end-of-life packages or vendor appliances. Dependency analysis indicates that five to fifteen percent of enterprise components are end-of-life. This requires an accepted-risk register rather than a developer backlog.
Falling behind on raw volume is standard across the software industry. Snyk vendor research recorded 459 million findings across 300,000 organisations, noting that 94% had a known fix, yet only about 10% were resolved. Resolving 10% of total findings makes you typical; resolving only 10% of KEV items means your process is broken. Volume alone does not equal risk. Establishing this exploitability ranking is the diagnostic baseline for any remediation program, ensuring you separate exploitation from intake noise and duplicates.
AI-assisted discovery vs AI-assisted validation — which side of the asymmetry should a mid-sized team invest in first?
Once you know which failure you have, the next question is which side of the asymmetry to fund. Fund validation first. Discovery capacity is abundant, cheap and improving quickly, while validation and absorption capacity is scarce, expensive and improving slowly. Spending on discovery lengthens the queue without reducing exposure. Fund discovery only where a named owner, a remediation budget and an established closure path already exist.
This imbalance dictates where resources belong. Automated discovery tools flood security pipelines with theoretical flaws. Without equivalent capacity to verify, triage and merge code changes, extra scanning generates administrative drag. Snyk’s internal benchmark data shows that six new security issues emerge for every one remediated, proving that automated assistants produce issues faster than engineers can absorb them. When the exploit window has collapsed, expanding your discovery tooling merely widens the gap.
This is why disclosure is outrunning patching across modern software delivery. One exception exists: if your proprietary, first-party codebase has never had an automated audit, running initial discovery is worthwhile. You own that code directly, understand its architecture, and can apply fixes without upstream maintainer dependencies.
Resist vendor pitches that bundle discovery and validation together. Discovery and validation address different engineering constraints with opposing returns. Purchasing both under one contract obscures which operational bottleneck is slowing your business down.
How do I evaluate whether to build an internal validation pipeline or buy a commercial remediation platform?
If validation is the scarce side, the only remaining question is who does it. Build only the thin layer that encodes your architecture; buy the rest. Buy exploitation intelligence and enrichment, build internal reachability and routing, and use Semgrep or GitHub Copilot Autofix on first-party code.
Building an internal harness is a software project. Cloudflare’s Vulnerability Discovery Harness and Validation System provides the public architecture for this approach: two decoupled stages where validation operates separately from discovery, evaluated on pipeline velocity rather than findings generated. That platform reflects a well-resourced engineering team. Replicating that infrastructure consumes two to four senior developers for several months, pulling them away from core product work.
Buying means paying for enrichment instead of building scanners. The real choice is who validates your findings. Commercial categories across the OWASP DevSecOps ASPM guidance span several approaches:
- Application Security Posture Management (ASPM): Platforms such as Endor Labs, Cycode, and Armorcode, which aggregate telemetry, deduplicate alerts, and map dependencies.
- Vulnerability management: Platforms like Qualys that track infrastructure assets and host configurations.
- Container and runtime remediation: Chainguard for minimal, rebuilt container images, alongside Contrast Security for runtime instrumentation.
- Agentic orchestration: Emerging systems designed to triage findings, deduplicate issues, and draft pull requests.
Ask these five questions before you commit budget:
- What is the verified false-positive rate on codebases matching your language stack?
- Does the platform deduplicate findings against your existing ticketing queue?
- Can the system distinguish reachable dependencies from inert code paths using your dependency graphs and SBOMs?
- How does the product handle unpatchable upstream packages?
- How does the vendor handle code privacy and model training data?
Before you sign, put vendor validation claims to the test on your own code.
What do I tell my board when the patch backlog keeps growing no matter what we do?
Everything above gets audited in one room, and the audit is not the ticket count. Stop reporting the ticket count. Tell your board what can hurt the business, what you are doing about it, and what resources you need.
When reporting security posture, use a three-part structure:
- What can hurt us: Your board line reads: “We have four reachable vulnerabilities across internet-facing services present in the CISA KEV catalogue.”
- What we are doing about it: Your board line reads: “Three resolve in this sprint’s maintenance window; the fourth requires architectural containment that product engineering is delivering this month.”
- What we need from the board: Your board line reads: “We require a formal decision to accept residual exposure on an unfixable upstream library, or capital funding to migrate to an actively maintained alternative.”
State unpatchable code paths directly. Dependencies nobody can patch are an operational constraint. Facing dependencies nobody can patch is part of modern software supply chains. Logging unfixable components in an accepted-risk register with compensating network controls is sound governance.
If you operate under APRA supervision, transparent reporting is a regulatory duty. Under APRA CPS 234, you must hold your material suppliers to capability commensurate with the exposure they create and notify material incidents within 72 hours. Similarly, the SOCI Act requires critical infrastructure asset classes to maintain a written risk management program signed off at board level. Similar oversight appears internationally, including United States SEC cyber governance expectations and CISA’s remediation deadlines for federal agencies.
Your queue did not grow because your team stopped working; it grew because discovery capacity outran absorption capacity across the entire software industry. A growing patch queue is an outcome of an industry where discovery tools outpace human absorption capacity. The only operational choice is whether to spend on finding more, or on closing what has already been found. Put the money into validation and reachability, and give your board a clear accounting of business risk. Explore where this issue sits within our broader series to balance detection against your team’s ability to ship fixes.
Frequently Asked Questions
How long can a KEV-listed vulnerability sit open before it counts as a failure?
Not long. Treat KEV-listed items in reachable, customer-facing components as band-one and hold them to a days-scale window, not a quarterly one. The exact number matters less than the breach rate: if more than a small share of band-one items pass their window in a month, the queue is broken rather than busy. Set the window, publish it, and report breaches instead of averages.
Does the 94% figure mean we should be closing nearly all of our findings?
No. A known fix is not an available fix. The upgrade may break an API, sit behind a major version jump, or arrive with a licence change. Snyk’s 94% measures whether a remediation exists somewhere, not whether it is safe to ship this sprint. Judge your queue by how many fixes you can absorb per week, not by how many fixes exist.
Is mean time to remediate a useful number to track?
Rarely. MTTR averages a KEV item in a customer-facing service with a low-signal finding in an internal tool, so it moves when intake volume changes rather than when exposure does. Track the age of the oldest unmitigated band-one item instead. It is one number a board can follow, and it cannot be improved by closing easy tickets.
Should we bulk-close stale tickets to get the backlog under control?
Only where the item is genuinely gone: component removed, service retired, or the finding proven unreachable and recorded as such. Bulk-closing by age is how teams lose the one thing the backlog was for, which is knowing what is still exposed. If a ticket is stale because nobody decided, route it to a named owner or accept the risk in writing.
What do we do with findings in vendor appliances and end-of-life systems we cannot patch?
Move them out of the working queue and into an exposure register with compensating controls attached: network isolation, WAF rules, reduced privilege, monitoring. Each entry needs an owner, a review date and a stated residual risk. These items will never close, and treating them as work in progress is what makes the whole queue look unmanageable.
What about a serious finding that does not have a CVE yet?
Work it from the advisory and your own reachability data. Pre-CVE findings have no EPSS score and no KEV entry, so rank them on exploit availability, component reachability and what an attacker gains. Route them through the same validation step as everything else. Waiting for an identifier is a decision to be uninformed for as long as the vendor takes to publish.
Can AI agents just clear the backlog for us?
They shorten validation, not absorption. An agent can deduplicate, test reachability, propose a patch and run the tests, which removes hours from every item. Someone still has to review the change, own the release and answer for the regression. Budget that saving as a multiplier on the closers you already have, not as a replacement for them.
How do we get product teams to take remediation work seriously?
Put it in their backlog with a name and a date, not in a security tracker they never open. Small, scheduled dependency upgrades prevent most of the queue, so negotiate a standing maintenance slice rather than ad hoc escalation. Where a fix is genuinely disruptive, escalate the decision, not the ticket: accept the risk explicitly or fund the work.
What can we do this quarter with no budget for vendors or hires?
Run the four measurements, then fix intake. Deduplicate against what is already open, suppress findings in components you do not deploy, and route everything else to an owner. Most 200-person teams find that a third of the queue is duplicate or unreachable. That work costs engineering time rather than licence money, and it changes the arithmetic before you ask for either.
How long should the diagnostic take, and what data do we need?
A week, if you have four things: twelve months of ticket history with open and close dates, your scanner’s current findings, a reachable component list or SBOM, and KEV and EPSS feeds. From those, pull weekly inflow and closure, age percentiles, the reachable KEV share and the duplicate rate. If any of the four is missing, that gap is your first finding.
Do we need a formal accepted-risk register, and who signs it?
Yes, if anything stays open on purpose. Each entry needs three fields: what the exposure is, why it is not being fixed, and when it will be reviewed. The signer should be the person who owns the affected service, not the security lead, because the risk sits with the service. Review quarterly, and bring the count of new acceptances to the board.
What happens if we simply stop trying to clear the backlog?
That can be a defensible position, provided you have classified what you are leaving behind: unpatchable residue, low-signal noise and a bounded set of accepted risks. It stops being defensible the moment a KEV-listed item in a customer-facing path sits past its window. Stop clearing everything, not the things that matter.
