OPINION
Most enterprises drowning in vulnerabilities don’t have a detection problem. They have an accountability problem wearing a detection problem’s clothing.
You can see it in how they spend. When a backlog gets big enough to reach the board, the reflex is to buy better scanning — wider coverage, faster cycles, richer threat intel, a single pane of glass. A year later, the organization has excellent visibility into a backlog that has grown.
That’s a misdiagnosis, not a tooling failure. Scanning capacity and remediation capacity are independent variables, and only one of them scales with a purchase order.
Point a modern scanner at an underinstrumented estate, and findings appear at a rate limited only by asset count and check depth. Remediation capacity is limited by engineering hours, change windows, application compatibility, vendor patch availability, and how much downtime the business will tolerate. None of that moves when you upgrade a license.
I watched authenticated scanning across a server estate triple our finding count in one quarter. Nothing had gotten less secure. We had just stopped being able to pretend we didn’t know.
Which produces a perverse incentive: If your program is measured on open findings, expanding coverage makes you look worse. Teams graded that way learn not to look.
What a Backlog Actually Measures
A backlog is a measure of unresolved ownership, not a measure of technical debt.
Think about what has to be true for one finding to close. Someone knows the asset exists. Someone is accountable for it. That person can change it. That person has time to change it. And that person has a reason to do it before their other work.
Scanning gets you the first one. The other four are governance.
That’s why two companies with identical tools, identical estates, and identical finding volumes can differ tenfold in how fast they fix things. Here are possible different situations:
-
No owner. The asset isn’t mapped to anyone. This is the most common failure and the worst, because a finding with no owner can’t be escalated — there’s nobody to escalate to. The unowned tail of your estate is also usually the oldest and most exposed part of it.
-
Owner without authority. A team is accountable but can’t act. The vendor controls the patch. Another team owns the platform. The application is contractually frozen. You get a queue that visibly misses a service-level agreement (SLA) while the assignee correctly points out they couldn’t have done anything.
-
Owner without capacity. Accountability and authority both exist, but remediation competes with feature delivery in the same backlog, refereed by a product owner whose bonus doesn’t mention security. Invisible in tooling — the tickets look assigned and in progress.
-
Owner without consequence. Everything’s in place and nothing happens, because missing a remediation SLA costs nobody anything. If your security reporting goes to the security team instead of the owner’s boss, this is your default state.
Escalating harder fixes exactly one of these.
Address Asset Ownership First
The highest-leverage move in an enterprise vulnerability program isn’t a scanning upgrade. It’s accurate, maintained asset-to-owner mapping.
It’s unglamorous work — reconciling the configuration management database (CMDB) against what scanners actually find, chasing the gaps, forcing a named owner onto every asset, including the ones nobody wants. It looks more like audit than security engineering, which is exactly why security teams underinvest in it.
Three rules: Ownership is a person or standing team, never a department — “infrastructure” can’t be paged or held to an SLA. The mapping is maintained, not established; reorgs invalidate it constantly. And an asset nobody will own gets escalated as a governance finding in its own right, separate from the vulnerabilities on it. That escalation produces owners faster than any amount of vulnerability reporting.
Open-finding count is the most-reported vulnerability metric and one of the least useful. It mixes detection coverage with remediation performance, moves for reasons unrelated to either, and can’t be attributed to anyone.
Try these instead:
-
Mean time to remediate, segmented by owning team — which turns a security metric into a management one.
-
SLA compliance rather than closure rate, because closure rate rewards clearing the easy stuff.
-
And percentage of estate with a verified owner, which is the leading indicator for everything else. Below 90%, none of your other numbers mean much.
In one program, time-to-remediate went from 45 days to 10 and SLA compliance from 30% to 95% over six months. Better tooling helped, but the tooling wasn’t the intervention. Findings started routing automatically to named owning teams. SLA breaches got reported to engineering leadership instead of to security. Exceptions got a real approval path. Unowned assets became governance findings.
Developer throughput went up over the same period.
And that’s a counterintuitive result worth sitting with. When remediation is owned, prioritized, and bounded, it stops being unplanned work interruptions and becomes schedulable. The friction was never the fixing. It was the ambiguity about who was supposed to fix what, and when.
Your scanners are fine. Go find out who owns your servers.
