How to Measure Vulnerability Remediation Programs

TL;DR

Organizations generally cannot remediate every vulnerability, so success requires prioritizing the issues that present meaningful risk instead of pursuing universal closure. A vulnerability management program should be evaluated through coverage, efficiency, velocity, and capacity, using operational data to compare remediation performance and identify practices associated with exceptional programs.

Transcript

All right, I think it's about time. Appreciate it, uh, everybody for coming. I'm Wade Baker. My colleague Ben Edwards here. We are from the Cyentia Institute. Today, we're gonna be talking about measuring vulnerability remediation. We're gonna share a ton of data. You're gonna see a ton of charts. And we hope those things, uh, interest you, and you... Read More

Key Insights

• Organizations cannot remediate every vulnerability in their environments because the volume of detected issues substantially exceeds their monthly closure capacity. The data indicates that remediation should be treated as a prioritization problem, with success defined by reducing meaningful risk rather than eliminating every recorded vulnerability.
• Remediation capacity scales with organizational size, but the proportion of vulnerabilities closed remains remarkably consistent across organizations. The observed relationship suggests that larger inventories bring larger remediation output without necessarily improving the underlying closure rate, although exceptional organizations can outperform the prevailing pattern.
• About ten percent of open vulnerabilities are closed by organizations each month according to the analyzed customer data. This relationship persisted across the observed period, making it a useful empirical benchmark for evaluating whether a program performs near, above, or below the broader organizational pattern.
• The vulnerability landscape contains a hundred and thirty thousand different vulnerabilities that could potentially affect organizations. Their prevalence is highly uneven, ranging from uncommon issues associated with niche or older software to broadly distributed weaknesses in software installed across many assets.
• A small but significant share of CVEs affects nearly everything in the analyzed environment. These widely distributed vulnerabilities arise in commonly installed software, which means their remediation can require substantially more organizational effort and coordination than issues confined to specialized assets or applications.
• Exploit availability can occur close to the publication of a CVE, and some proof-of-concept or exploitation activity exists before official publication. The disclosure date can therefore act as a trigger for exploitation, leaving defenders with little time to identify, prioritize, and remediate relevant exposure.
• Unexploited vulnerabilities do not present the same practical concern as vulnerabilities that attackers can use. The central management challenge is therefore distinguishing issues that warrant urgent action from the much larger pool of detected weaknesses that may never be exploited.
• A holistic vulnerability management assessment uses coverage, efficiency, velocity, and capacity. These measures examine different aspects of program performance and allow organizations to compare results, recognize exceptional practices, and replace an unrealistic fix-everything objective with a more practical definition of success.

Questions & Answers

Q: Can organizations remediate every vulnerability they find?

Organizations generally cannot remediate every vulnerability in their environments. The analyzed data shows a strong relationship between the number of issues open at the start of a month and the fraction closed, with organizations typically resolving about ten percent monthly. This constraint appears across organizations of different sizes, so universal remediation is not a realistic operational goal.

Q: What is a realistic monthly vulnerability closure rate?

About ten percent of open vulnerabilities are closed each month in the analyzed organizational data. The pattern remains relatively stable as environment size changes, meaning organizations with larger inventories close more issues in absolute terms but retain a similar proportional rate. Some organizations perform much better, so the observed rate is a benchmark rather than an unavoidable limit.

Q: Why should vulnerability programs prioritize instead of fixing everything?

Prioritization is necessary because vulnerability inventories are much larger than the capacity available to remediate them. Treating every issue as equally urgent creates an unwinnable objective and ignores whether a weakness is likely to be exploited. A more practical strategy focuses limited remediation effort on vulnerabilities that represent meaningful risk within the organization's actual environment.

Q: How quickly can exploit code appear after a CVE is published?

Exploit code or a known proof of concept can become available close to the publication of a CVE. In some cases, exploitation or proof-of-concept activity exists before official publication. Publication can also trigger exploit development, so defenders may have little time to identify affected assets and act before a vulnerability becomes usable by attackers.

Q: What kinds of vulnerabilities affect the most assets?

Vulnerabilities in widely installed software affect the greatest number of assets in the analyzed customer environments. The transcript identifies commonly deployed products, including Windows and Acrobat, as examples of software whose bugs can appear across many systems. By contrast, vulnerabilities in niche libraries, specialized software, or older technologies tend to affect fewer assets.

Q: How should a vulnerability management program be assessed?

A vulnerability management program should be assessed through coverage, efficiency, velocity, and capacity. Together, these measures provide a holistic view of what the program reaches, how effectively it uses remediation effort, how quickly it acts, and how much work it can complete. Comparing these dimensions across organizations can reveal exceptional performance and useful improvement practices.

Q: What does remediation capacity mean for vulnerability management?

Remediation capacity is the amount of vulnerability work an organization can complete within a given operating period. The data indicates that capacity rises with the size of the vulnerability inventory, but organizations still close a similar share of their open issues. Understanding this constraint helps teams set achievable goals and direct effort toward the most consequential vulnerabilities.

Q: Why is fixing vulnerabilities before exploitation difficult?

Fixing vulnerabilities before exploitation is difficult because exploit availability can closely coincide with official CVE publication, while organizations can remediate only a fraction of their open issues during a month. Some exploitation or proof-of-concept activity even precedes publication. The combination of limited capacity and a compressed timeline makes accurate prioritization essential to reducing practical risk.

Summary & Key Takeaways

• The research uses platform data covering hundreds of organizations to examine vulnerability remediation as a measurable operational process. Rather than assuming every detected issue can be fixed, the analysis asks practical questions about vulnerability volume, organizational performance, exploit timing, and the characteristics that distinguish stronger remediation programs from weaker ones.

• The data shows a consistent relationship between the number of vulnerabilities open at the beginning of a month and the fraction closed during that month. Organizations typically close about ten percent of their vulnerabilities monthly, and this relationship appears to scale with organizational size, although some organizations perform substantially better than the general pattern.

• Because remediation capacity is limited and exploit code can appear near the publication of a CVE, fixing every issue before possible exploitation is unrealistic. The proposed alternative is to assess programs holistically through coverage, efficiency, velocity, and capacity, then use those measures to prioritize work and identify achievable improvements.