Vulnerability Management: Why the Backlog Grows Faster Than You Patch

Almost every organisation that buys a scanner ends up in the same place within six months: a backlog of several thousand findings, a patching team that cannot keep pace, and a monthly report where the number only ever goes up.

The problem is rarely the tooling. It is that severity was treated as priority.

Severity is not priority

CVSS measures how bad a vulnerability would be in a worst-case deployment. It knows nothing about yours. A critical rating on an internal service reachable only by three administrators is a lower priority than a medium on your public login page.

Three questions turn severity into priority:

• Is it reachable? Internet-facing, internal, or only from a host nobody can log into?
• Is it being exploited? Exploit prediction scores and the known-exploited catalogues published by national authorities are far better signals than severity alone. A medium with a public exploit in active use outranks a theoretical critical.
• What does it sit on? The same flaw on a payment service and on a meeting-room display are not the same risk.

Combining those three usually reduces a "critical" list of hundreds to a genuine worklist of a dozen or so.

Find the asset owner before you find the vulnerabilities

The most common reason a finding stays open for a year is that nobody knows whose server it is. An asset inventory with a named owner per system is unglamorous and it is the single highest-leverage thing in this process.

Without it, every finding needs a small investigation before anyone can be asked to fix it, and that investigation cost is what kills the programme.

Set remediation targets you can actually meet

A policy demanding all criticals in seven days sounds rigorous and is routinely ignored, which teaches everyone that the policy is decoration. Pick targets your teams can hit, measure against them, then tighten.

A workable starting point: internet-facing and known-exploited within days; internet-facing high within a few weeks; internal high within a quarter; everything else into the normal patch cycle.

Accept risk explicitly, in writing

Some findings will not be fixed. Legacy systems, vendor software with no patch, appliances past end of support. Pretending otherwise leaves them in the backlog forever, inflating the numbers and hiding the things you could fix.

Record the decision, the compensating control, the owner and a review date. An accepted risk with a named owner is a managed problem. The same risk sitting unremarked in a spreadsheet is an incident waiting to be explained.

Measure flow, not stock

The total open count mostly reflects how much you scan. More useful numbers:

• Median time to remediate, split by severity and by internet exposure.
• How many findings are older than your own policy target.
• How many were introduced this month versus closed this month.
• How many recur after being closed — the clearest sign that a build process keeps reintroducing them.

That last one is where real improvement comes from. A vulnerability that reappears each time a container image is rebuilt is not a patching problem, it is a base image problem, and fixing it once removes it permanently.

Close the loop

Verify fixes by rescanning rather than trusting the ticket. A meaningful proportion of closed tickets have not actually changed the running system — the patch was applied to one node in a pool, or the service was never restarted.

Frequently asked questions