In today’s rapidly evolving cybersecurity landscape, managing vulnerabilities in open-source components has become increasingly complex. While traditional approaches relying solely on CVSS scores have their merits, they may not be sufficient to address the exponential growth in discovered vulnerabilities. A more nuanced and scalable approach is needed, one that considers not only severity but also exploitability and potential impact.
The Evolution of Vulnerability Management
In the past, I was solely using CVSS scores in the vulnerability management policy. It was a strict approach: no new vulnerabilities were to be introduced into production, as we didn’t want to ship defects downstream. We had an SLO (Service Level Objective) for remediating newly discovered vulnerabilities in open-source components already in production, based on CVSS scores:
This policy, along with a robust application security program, reduced organizational vulnerabilities by 99% in under two years! However, while effective, it might not be scalable for all organizations, especially given the year-on-year exponential increase in discovered vulnerabilities.
Beyond CVSS: A Multi-Faceted Approach
The Common Vulnerability Scoring System (CVSS) provides a standardized method for assessing the severity of vulnerabilities. However, it falls short in considering context-specific factors such as exploitability in an organization’s environment and the potential impact on business operations.
To create a more effective vulnerability management policy, organizations should consider three key factors:
1. Severity (CVSS Score)
2. Exploitability
3. Potential Impact
Assessing Exploitability
Vulnerabilities that are actively exploited in the wild should take precedence over those without known exploits. The Stakeholder Specific Vulnerability Categorization (SSVC) model (mentioned in the previous episode) incorporates exploitability as a primary factor in its decision tree.
One approach to determining exploitability is using the Exploit Prediction Scoring System (EPSS). EPSS provides a probability score (0-100%) indicating the likelihood of a vulnerability being exploited within the next 30 days. It is a data-driven, machine learning model that uses current threat information and real-world exploit data to predict exploitation likelihood. It focuses on predicting actual exploitation attempts, not just theoretical exploitability. And the scores are updated daily based on the latest threat intelligence and exploitation activity observed in the wild.
Evaluating Potential Impact
The potential impact of a vulnerability exploit is another crucial factor. In the SSVC model, this is referred to as “technical impact” and “mission & well-being”. For most organisations, this would be the classification of the asset that has the vulnerability. Classifications are usually done based on the sensitivity of the workloads the asset managed or stores and the criticality of the application to the business functions. In additional to that, considerations need to be made to both internet facing applications and applications that are used for record keeping (source of truth for stored data).
A Balanced Policy Framework
Rather than abandoning CVSS scores entirely, a balanced approach incorporates CVSS ratings supplemented by considerations for potential impact and exploitability. Here’s a suggested framework:
1. Asset Classification: Ensure all applications are classified based on criticality and sensitivity.
2. Pipeline & Continuous Scanning: Implement software composition analysis scanning in the build pipeline and for production systems. I’ve seen organisation where the continuous scanning is done on the code repository, which. Is not always reflective of what’s running in production
3. Tiered Policies: For highest-classification applications, maintain a strict “no new medium or above vulnerabilities” policy. For less critical systems, incorporate exploitability considerations.
4. Existing Vulnerabilities: Apply a similar classification system for newly discovered vulnerabilities in existing open-source components.
5. Exception Process: Establish a formal exception process for cases where releasing applications with known vulnerabilities outside of policy is necessary (e.g., non-security production incident patches).
Conclusion
An effective open-source vulnerability management policy must balance the need for security with the realities of modern software development. By considering severity, exploitability, and potential impact, organizations can create a more nuanced and practical approach to managing vulnerabilities. This balanced strategy allows for prioritization of the most critical issues while maintaining a scalable and sustainable vulnerability management process.