The cycle
Vulnerability management is the recurring process of identifying known flaws in an organization's assets, ordering them, fixing them, and confirming the fix took.
The cycle is mature and well documented. Scan, triage, assign, remediate, verify, repeat. Most sizeable companies have had this running for years.
Why the queue never empties
Because intake exceeds output, structurally.
New CVEs are published every day, and the estate grows. An organization fixing a thousand items per quarter and receiving twelve hundred is not failing at execution: it is operating in a regime where accumulation is the normal condition.
The practical consequence is that the question stops being how to empty the queue and becomes what to do first. And that is where most programs go wrong, because they sort by technical severity.
The problem with sorting by severity
CVSS describes a flaw's potential damage under conditions ideal for the attacker. It does not know whether that component is reachable in your environment, nor whether anyone is exploiting it today.
The result is a queue whose order bears no relation to risk. 9.8 flaws published years ago with no known exploit sit at the top. Medium-scored flaws in active campaigns sit at position 400. The team works top down, with discipline, and the item that would take the company down stays put.
Three signals reorder it better: confirmed real-world exploitation, the existence of a working public exploit, and estimated near-term exploitation probability. Combined with blast radius, they give an order that corresponds to risk.
The blind spot the discipline has by construction
Vulnerability management works over the inventory it was handed. It is excellent at that and blind to what sits outside the list.
An asset nobody registered is not scanned, produces no finding, and appears in no report. The report comes out clean on an incomplete scope, and clean is worse than empty, because it produces confidence.
This is why the discipline completes itself with attack surface management, which answers a different question: which assets exist. One produces the list, the other works over it.
On measuring
MTTR measures the team's execution capacity and nothing else. A count of open items measures the volume a tool produces. Neither says whether the queue is in the right order.
The number that answers that is the share of findings that went through exploitability validation, because it separates a queue of findings from a queue of problems.