The Vulnerability Management Backlog Every Organization Has and Nobody Talks About
Vulnerability management programs have a dirty secret that annual security assessments and compliance audits politely decline to examine: the remediation backlog. Organizations that have deployed vulnerability scanners — Tenable, Qualys, Rapid7 — know their vulnerability count precisely. Most of them have more open vulnerabilities than they will remediate in the coming year. Many have more open vulnerabilities than they will remediate in the next three years at their current remediation pace.
The vulnerability count is not the problem. Vulnerability counts in large enterprise environments are inherently large because the number of systems, applications, and network devices in scope is large and each can be running software with known vulnerabilities. The problem is the remediation throughput: the rate at which the security team can identify, prioritize, assign, track, and confirm remediation of vulnerabilities. In most organizations, this rate is lower than the rate at which new vulnerabilities are discovered.
The Prioritization Failure
Vulnerability management programs that prioritize by CVSS score — the Common Vulnerability Scoring System numeric score that accompanies every CVE — are prioritizing by the wrong metric. CVSS scores measure the theoretical severity of a vulnerability in ideal exploitation conditions. They do not measure the probability that this specific vulnerability will be exploited against this specific organization given current attacker behavior, the presence of other compensating controls, or the actual exploitability of the vulnerability in the organization’s specific configuration.
The consequence of CVSS-based prioritization is a remediation queue that is populated by vulnerabilities with high severity scores rather than by vulnerabilities that represent high risk to the organization. A critical CVSS vulnerability that has no public exploit code, that exists in software deployed only on an internal-facing server that is not accessible from the internet, and that is mitigated by other controls in the environment is lower priority than a medium CVSS vulnerability that has active exploitation in the wild, that exists in internet-facing software, and that has a direct path to the organization’s sensitive data.
The Exploit Prediction Scoring System — EPSS — provides a probability score for vulnerability exploitation based on current threat intelligence. Organizations that incorporate EPSS into their vulnerability prioritization produce remediation queues that reflect actual risk more accurately than CVSS-based queues and allocate the limited remediation capacity to the vulnerabilities that matter most.
The Remediation Capacity Problem
Vulnerability remediation is not a security team function. It is an IT operations function. The security team identifies vulnerabilities. The IT operations teams — server administrators, network engineers, desktop support, application teams — remediate them by applying patches, changing configurations, or implementing mitigating controls.
The capacity constraint for vulnerability remediation is therefore not the security team’s capacity but the IT operations team’s capacity. A security team that produces comprehensive, well-prioritized vulnerability reports faster than the IT operations teams can absorb and act on them is creating a backlog that the security team cannot reduce by working harder. The backlog reduction requires either more IT operations capacity or a reduction in the volume of vulnerabilities that require remediation.
The organizational dynamic that makes this problem persistent is the separation between vulnerability identification — which is the security team’s responsibility and performance metric — and vulnerability remediation — which is the IT operations team’s responsibility but not typically their primary performance metric. IT operations teams that are measured on system availability and change management quality have little incentive to prioritize vulnerability remediation over other work unless explicit expectations and accountability are established.
What Risk-Based Vulnerability Management Looks Like
The vulnerability management programs that produce defensible security postures rather than large open vulnerability counts share a set of practices. They prioritize based on exploitability and organizational exposure rather than CVSS score. They establish service level agreements with IT operations teams for remediation of prioritized vulnerabilities that carry the same organizational weight as other IT service level commitments. They track remediation SLA compliance and escalate violations. They report to executives in terms of risk reduction rather than vulnerability counts.
These programs look less like security team reporting functions and more like cross-functional risk management programs. That is what effective vulnerability management requires. The vulnerability scanner output is the input. The organizational process that converts that input into reduced risk exposure is the program. Organizations that have the input and not the program are measuring their risk without reducing it.