Vulnerability Backlog Math: Why Your Queue Never Shrinks

Someone asks why the vulnerability backlog is bigger than last quarter, despite the team patching more than ever. The honest answer is not a management failure or a tooling gap. It is arithmetic, and it has been well understood in queueing theory since 1961.

The Backlog Is a Queue, and That Changes the Question

A vulnerability backlog has every property of a queue. Items arrive, wait, get served, and leave. Once you accept that framing, the interesting question stops being "how big is the backlog" and becomes "what are the two rates".

Little's Law, Applied to CVEs

Little's Law states that for a stable system, the average number of items in the system equals the average arrival rate multiplied by the average time an item spends in the system:

L = lambda x W

L      = average number of items in the system  (backlog size)
lambda = average arrival rate                   (new findings per week)
W      = average time in the system             (time to remediate)

It needs one assumption, and it deserves stating honestly: the system must be observed over a long enough period to be roughly steady. A vulnerability backlog is only approximately such a system, since arrivals are bursty and capacity fluctuates. Over a quarter, the approximation is good enough to reason with, and far better than the intuition it replaces.

Two conclusions follow, and most metrics advice gets both wrong.

First: backlog size and mean time to remediate are not independent KPIs. You cannot improve them separately, because they are two terms in the same product. At steady state, with arrivals fixed, reducing time in system is the only lever that reduces backlog. A target that says "cut the backlog by 30% and cut MTTR by 30%" is asking for one thing twice.

Second: if arrival rate exceeds throughput, no prioritisation scheme empties the queue. Prioritisation changes the order of the queue. It never changes its length. This is the single most useful thing on this page.

Measuring Arrival Rate Honestly

Arrival rate is new relevant findings per week after stack matching, not raw CVE publication volume.

That distinction matters enormously. Roughly 130 CVEs are published globally per day, and the count of those that touch your estate is smaller by orders of magnitude. Measuring the global figure produces a terrifying number that no decision depends on, which is the definition of a bad metric. We made the case for filtering before measuring in why most CVE alerts are noise.

Measure lambda after matching, in findings per week, averaged over at least a quarter to smooth the bursts.

Measuring Remediation Throughput

Throughput is findings closed per week, where closed means genuinely resolved: patched, mitigated, or formally risk-accepted with an owner and a review date.

Two traps. Do not count an item as closed because the ticket was closed as duplicate or stale; that is leakage, not throughput. And do not count re-detections of the same unfixed item as new arrivals, or you will inflate both rates and learn nothing.

Why Prioritisation Does Not Shrink a Queue

If lambda is greater than throughput, the backlog grows. Full stop. Better prioritisation means the right items are at the front, which is genuinely valuable, but the queue still lengthens.

There are exactly three responses, and every honest programme is doing one of them:

1. Raise throughput. More capacity, better automation, faster patch paths.
2. Lower arrival rate. Consolidate the estate, upgrade off end-of-life software, retire systems. Fewer distinct technologies means fewer matches. This is the lever nobody reaches for and it is by far the most durable.
3. Formally accept the difference. Write down that items below a defined threshold will not be worked, and get that decision signed off.

Presenting a burndown chart without an arrival-rate line implies a fourth option that does not exist. That is how vulnerability programmes lose credibility with leadership: not by having a backlog, but by being visibly surprised each quarter that it did not shrink.

The MTTR Clock Problem: From What Start Point?

MTTR from disclosure, from detection, or from ticket creation are three different numbers for identical work, and they can differ by weeks.

Vendor benchmarks almost never state which they used, which makes cross-organisation comparison meaningless. Pick one, define it in writing, and never compare across definitions.

The most defensible choice is from detection, meaning the moment the finding entered your system, because it measures what you control. Measuring from disclosure blends your response time with your detection latency and hides which one is the problem.

Five Metrics Worth Reporting

1. SLA compliance rate, broken out by severity tier. The percentage of items closed within the deadline your policy sets, per tier. This is the metric that tests the policy from our patch management strategy rather than describing activity.

2. Exposure window for KEV-listed items, measured from the KEV addition date to remediation.

This is the best single external metric you have, and the reason is worth spelling out: the KEV addition date is a public, dated fact published by CISA. An auditor, a customer or a board member can independently verify both ends of that clock. Almost no other security metric has that property. Our KEV catalog explainer covers how entries get added and what inclusion actually means.

3. Net backlog change per period. Arrivals minus closures. One signed number that tells leadership the direction of travel in a way a total never can.

4. Count of risk-accepted items past their review date. Risk acceptance is legitimate. Risk acceptance that silently became permanent is a governance failure, and this number finds it.

5. Percentage of the estate with a named owner. Unowned systems are where remediation goes to die. This metric predicts the others.

Three Vanity Metrics to Retire

Total vulnerability count. It moves for reasons unrelated to your work: adding a scanner, updating a vulnerability database, or onboarding a repository all change the number while your exposure is unchanged. It is dominated by findings that are unfixable or irrelevant. Report net change in the actionable backlog instead.

Average CVSS across the backlog. This averages a non-linear, roughly ordinal scale. The mean of 9.8 and 4.0 is not a meaningful description of anything, and the number barely moves even when the composition changes drastically. It is a statistic that cannot be acted upon.

Scan coverage percentage. It measures the tool, not the estate. Coverage is computed against the asset list the scanner knows about, so anything your inventory missed is invisible to both the scan and the coverage figure. It reliably reads 98% right up until the incident happens on the 2%.

The Capacity Conversation With Leadership

Little's Law turns an argument about diligence into an arithmetic discussion, which is a much better conversation to be in.

Bring three numbers: arrival rate, throughput, and the gap. Then present the three responses above as options with costs, rather than promising a burndown you cannot deliver. "We close 40 a week, 55 arrive, here are three ways to close a 15-item gap" is a budget conversation. "We are working very hard on the backlog" is not.

Instrumenting It: The Events You Need to Emit

None of the five metrics can be computed retroactively unless you record three timestamps and an owner per finding:

• detected_at: when it entered your system.
• triaged_at, with the decision made.
• closed_at, with the resolution.
• owner: a person, not a team alias.

That is the whole instrumentation requirement. Everything above is a query over those four fields.

This is also where a workflow beats a feed. Our per-CVE states, open, in progress, deferred, risk accepted and closed, with notes on each transition, exist precisely to turn a stream of findings into countable events with dates. The same reasoning shapes the risk heatmap: it deliberately excludes anything closed, archived or risk-accepted, so it shows outstanding work rather than lifetime volume, which is exactly the distinction between backlog and total count that this article is about. Ticketing and workflow are Premium and Max features, listed on the pricing page.

What a Good Monthly Slide Looks Like

One slide, five lines, no chart junk:

• Arrivals this month, closures this month, net change.
• SLA compliance by tier, as three percentages.
• KEV exposure window, median and worst case.
• Risk-accepted items past review date, as a count.
• Estate ownership coverage, as a percentage.

Nobody needs the total. They need to know whether the queue is growing, whether you are hitting the deadlines you set, how long verified-exploited items stayed open, what you have consciously accepted, and who is accountable.

Measure the two rates first. Everything else is downstream of them.