Updates from the CVSS SIG

Updates from the CVSS SIG

Speakers: Nick Leali, CVSS SIG Co-chair, Incident Manager at Cisco PERT

Conference: VulnCon

YouTube: https://www.youtube.com/watch?v=etDcVPpOuo8

Overview

This talk, presented by Nick Leali, a co-chair of the Common Vulnerability Scoring System (CVSS) Special Interest Group (SIG), provides a comprehensive update on the state of CVSS version 4 (v4). Leali details the significant strides made in v4 adoption across the industry, highlighting the contributions of various vendors, the CVE program, and NVD. The presentation also addresses ongoing efforts by the SIG to enhance documentation, provide clearer guidance, and tackle challenges related to the implementation and interpretation of the new standard.

Leali, drawing from his extensive experience as an incident manager at Cisco PERT and his previous role in third-party software management, emphasizes the practical application of CVSS within large organizations. He shares insights into the critical discussions surrounding CVSS vector reassessment, a process enabling vendors to generate platform-specific vulnerability scores that more accurately reflect risk within their unique product ecosystems. The talk is particularly relevant for vulnerability managers, security engineers, and developers who rely on CVSS for prioritizing remediation efforts and understanding the true impact of security flaws.

The updates from the CVSS SIG are crucial because CVSS remains a foundational standard for communicating vulnerability severity. As the cybersecurity landscape evolves, the need for a more granular, context-aware scoring system has become paramount. CVSS v4 aims to meet this demand, and Leali's presentation illuminates the progress, challenges, and future direction of this vital initiative, helping organizations navigate the transition and leverage the full potential of the updated standard for more effective risk management.

Background

▶ Watch: Introduction and talk agenda for CVSS SIG updates (0:00)

The Common Vulnerability Scoring System (CVSS) has long served as a standardized, open framework for communicating the characteristics and impacts of IT vulnerabilities. Its primary goal is to provide a numerical score representing the severity of a vulnerability, allowing organizations to prioritize remediation efforts. However, prior versions, particularly CVSS v2 and v3.x, faced increasing scrutiny for their limitations in accurately reflecting the real-world impact of vulnerabilities across diverse environments.

One of the most prominent criticisms revolved around the "one-size-fits-all" nature of a single, generic CVSS score issued by entities like the National Vulnerability Database (NVD) or the CVE program. As noted in the talk, this approach often failed to account for the nuances of how a vulnerability might manifest or be exploited on different platforms, products, or configurations. A vulnerability deemed "critical" (e.g., a 9.8 score) in a general context might have a significantly lower impact—or even no impact—within a specific vendor's product due to mitigating controls, architectural differences, or environmental factors. This disconnect led to significant challenges in prioritization, with organizations struggling to justify lower remediation urgency for vulnerabilities that official scores deemed extremely severe, as famously articulated in a blog post by the developer of Curl, titled "CVSS is dead to us." This sentiment underscored a growing industry need for more context-based risk assessment rather than purely objective, abstract scores.

The development of CVSS v4, therefore, was driven by a necessity to introduce greater fidelity and flexibility into the scoring system. The CVSS SIG, composed of passionate contributors and users, embarked on an extensive effort to refine the metrics, incorporate supplemental metrics, and introduce concepts like the split between vulnerable system and subsequent system impacts. These enhancements aimed to provide a more nuanced framework that could better support vendor-specific assessments and allow for a more accurate reflection of risk in the complex, interconnected software development and deployment environments prevalent today. The ongoing work of the SIG, as highlighted by Leali, focuses not just on the technical specification but also on providing robust documentation, examples, and tools to aid in the adoption and effective use of CVSS v4 across the vulnerability information ecosystem.

Key Findings

▶ Watch: Key vendors and programs adopting CVSS v4 (2:40)

The talk delivered several key findings regarding the adoption, challenges, and future direction of CVSS version 4:

• Significant CVSS v4 Adoption: CVSS v4 has seen substantial uptake since its release. Leali reported that the CVE program and NVD have both integrated tooling support for v4 vectors. The CVE program alone has accumulated over 5,000 CVSS v4 vectors in its database. GitHub stands out as the largest producer, with more than 8,000 CVSS v4 vectors, encompassing both reviewed and unreviewed data. In total, 56 unique vendors are currently producing CVSS v4 scores, with VDB, Juniper, Intel, Siemens, and various national Computer Emergency Response Teams (CERTs) like ICSERT and CISA being among the largest contributors to the CVE database.
• Ongoing Documentation and Guidance Improvements: The CVSS SIG is actively enhancing supporting documentation. This includes adding new examples for complex vulnerability types such as serverside request forgery (SSRF), cross-site request forgery (CSRF), cross-site scripting (XSS), and regression flaws, along with clarifications for subsequent system impacts. The FAQ has also been expanded to address common questions, particularly regarding the underlying math of CVSS v4, guidance on implementing calculators, and the crucial concept of CVSS vector reassessment.
• Emphasis on Vendor-Specific Vector Reassessment: A significant finding and point of discussion was the practice of vendors generating new, platform-specific CVSS vectors for existing CVEs. This allows vendors to provide an assessment that is more appropriate to their unique products or platforms, addressing the limitations of generic NVD scores. While this practice introduces a potential "disconnect" between generic and vendor-specific scores, the SIG views it as essential for providing more relevant per-platform assessments.
• Positive Sentiment Towards CVSS v4: A survey conducted by the CVSS SIG in 2024, with over 500 responses, revealed a largely favorable opinion of CVSS v4. 74% of respondents expressed a favorable view, indicating it was "worth moving to CVSS version 4." Among organizations that have already adopted v4, 85% of both consumers and producers believe the move was worthwhile.
• Challenges to Adoption: Despite the positive sentiment, several challenges hinder wider adoption. These include lagging tool support (e.g., initial delays in CVE/NVD, ongoing work in CESAF), the time and complexity involved in updating internal tools, and persistent concerns about the math behind the scoring. No single reason dominates, suggesting a multifaceted problem.
• Multi-System Vulnerability Prioritization: The survey highlighted that CVSS rarely operates in a vacuum. Over one-third of organizations use two or more scoring systems as part of their vulnerability management programs. These often include Stakeholder-Specific Vulnerability Categorization (SSVC), Exploit Prediction Scoring System (EPSS), vendor-provided scores, and internally developed systems, indicating a trend towards holistic risk assessment.
• Future Stability and "Enhanced User Guide": The SIG plans for CVSS v4 to remain stable for a considerable period, with no new standard expected in the near future (potentially a v4.1 update in 2026, but not 2025). A major focus is the development of an "enhanced user guide" or implementation guide. This guide aims to help end-consumers and vulnerability management system owners mature their use of CVSS and "level up" their assessment processes.

Technical Deep Dive

▶ Watch: Latest updates to CVSS v4 documentation and FAQ (4:00)

The technical discussions in the talk centered not just on the core mechanics of CVSS v4 metrics, but significantly on its practical implementation, particularly regarding vendor-specific vector reassessment and the challenges in data exchange and schema definition.

A cornerstone of CVSS v4's enhanced utility, and a major point of discussion, is the concept of vector reassessment. This process allows a vendor to take an existing CVE, which might have a general CVSS score published by NVD or the original vendor, and generate a new, specific base vector string tailored to how that vulnerability impacts their particular product or platform. Leali provided an example: an OpenSSL vulnerability with a generic NVD score might affect Cisco's environment. Cisco would then assess this vulnerability against its diverse product line (e.g., "17 different routers, all the wireless stuff") and produce a unique CVSS v4 vector for each affected platform. This ensures the assessment is "more appropriate to the platform," acknowledging that impact can vary drastically between a workstation, a server, a router, or a firewall, even for the same underlying CVE. The speaker clarified that while the assessment changes, the standard itself (the set of vectors, their definitions, and the calculation methodology) remains consistent.

The technical implications of this reassessment are profound. It shifts the paradigm from a universal, objective score to a more context-aware risk evaluation. However, it also introduces complexities:

• Data Exchange Standard: Leali highlighted the need to "solve and work on the data exchange standard" for these per-product assessments. This refers to how these unique vendor-specific vectors can be effectively communicated and consumed by customers, especially when they differ from the original CVE score.
• Schema Definition Challenges: An audience member raised a critical technical question regarding the CVSS v4 schema, specifically asking about the computation of threat score, threat severity, environmental score, and environmental severity. The attendee noted difficulty in finding clear guidance on how these are calculated, which is crucial for valid schema implementation in tools like CESAF (Common Event Specification Format). Leali acknowledged this as a "complex decision" area where the SIG "can do a better job at helping producers and consumers to make those decisions" and expressed openness to suggestions for improvement in examples and guidance. This highlights a gap in the current technical specification or its accompanying documentation that needs to be addressed for smooth integration.
• JSON Schema Versioning: Another technical detail brought up by an implementer was the recommendation to use Draft 2020-2012 JSON schema for any future CVSS v4 JSON schemas. This specific version offers "additional fields" and resolves "incompatibilities with older versions," making integration easier for tools like CESAF 2.1, which is slated to include CVSS v4 support. This underscores the importance of adhering to modern schema standards for interoperability in the broader vulnerability information ecosystem.

Leali also touched upon the fidelity improvements in CVSS v4, mentioning "supplemental metrics" and the "split of vulnerable system and subsequent system" as key differentiators from v3. While the talk didn't delve into a detailed breakdown of each v4 metric, it emphasized that "the numbers are different. The numbers will change." Organizations transitioning to v4 "need to understand how those things are going to change in your environment." He referenced an "amateur tool" he developed to help analyze these changes based on an organization's specific data, indicating the necessity for a careful, data-driven approach to migration rather than a simple "drop-in replacement." This technical shift requires not just tool updates but also a re-evaluation of internal processes and risk models.

Demo / Proof of Concept

▶ Watch: Debate: Vendor-specific vs. standardized CVSS scores (6:40)

While the speaker, Nick Leali, referenced an "amateur software developer" tool he created to help organizations analyze the impact of CVSS v4 adoption in their environments, this particular conference talk did not include a live demonstration or proof of concept of that tool. Leali mentioned that the tool's link was available on Discord and encouraged interested attendees to check it out for themselves. The focus of the presentation was primarily on updates from the CVSS SIG, adoption statistics, and discussions around the standard's evolution rather than a direct technical showcase of a specific implementation.

Defensive Implications

▶ Watch: How to justify vendor-specific CVSS scores to regulators (8:00)

The updates and discussions surrounding CVSS v4 present several critical implications for defenders and vulnerability management programs:

1. Prioritize CVSS v4 Adoption and Training: Organizations should actively evaluate and plan for the adoption of CVSS v4. Given its "more fidelity" and improved context, v4 offers a more accurate basis for risk assessment than previous versions. Defenders must invest in understanding the new metrics, the "split of vulnerable system and subsequent system," and the calculation methodologies. Training for security teams on v4 is essential to ensure consistent and accurate scoring.
2. Embrace Vendor-Specific Assessments: A key defensive strategy should be to actively seek and prioritize vendor-specific CVSS v4 scores for vulnerabilities affecting their products. While a generic NVD score might rate a vulnerability as a "nine," a vendor's reassessment, based on their specific platform, might genuinely reduce its impact to a "three." Defenders should advocate for using these more accurate, contextual scores, even if it means addressing potential "disconnects" with leadership or regulatory bodies who might still reference generic NVD scores. This requires clear communication and a robust internal process for justifying these discrepancies.
3. Integrate Multiple Scoring Systems: The survey results clearly indicate that CVSS does not operate in a vacuum. Defenders should move beyond relying solely on CVSS and integrate it with other complementary scoring and prioritization systems like EPSS (for exploitability likelihood), SSVC (for decision-making pathways), and internal risk models. This holistic approach provides a richer, more actionable understanding of vulnerability risk, enabling more effective resource allocation.
4. Prepare for Tooling and Process Updates: The transition to CVSS v4 is not a "drop-in replacement" for v3. Defenders must anticipate significant effort in updating their internal vulnerability management tools, custom scripts, and reporting mechanisms to support v4 vectors and calculations. This includes ensuring compatibility with updated JSON schemas (e.g., Draft 2020-2012 JSON schema for CESAF 2.1). The complexity of these updates should be factored into planning and resource allocation.
5. Leverage SIG Documentation and Engage with the Community: The CVSS SIG is actively developing an "enhanced user guide" and updating FAQs and examples. Defenders should proactively utilize these resources to mature their vulnerability management programs. Furthermore, engaging with the CVSS SIG by providing feedback, suggesting examples, or asking questions can directly contribute to improving the standard and its guidance, benefiting the entire defensive community.
6. Understand Score Changes: As Leali noted, "the numbers are different. The numbers will change." Defenders must anticipate that vulnerabilities scored under v4 might yield different severity ratings than under v3. This requires careful analysis, potentially using tools (like the one Leali mentioned) to model the impact of v4 on their specific vulnerability data, and adjusting internal risk thresholds accordingly.

By proactively addressing these implications, defenders can leverage CVSS v4 to build more accurate, context-aware, and efficient vulnerability management programs, ultimately improving their organization's overall security posture.

Key Takeaways

• CVSS v4 is Gaining Significant Traction: The new standard is seeing widespread adoption, with 56 unique vendors producing scores, and major platforms like GitHub, CVE, and NVD integrating support. A 2024 survey indicates 74% favorable opinion among respondents.
• Vendor-Specific Assessment is Crucial: CVSS v4 enables vector reassessment, allowing vendors to provide more accurate, platform-specific vulnerability scores for their products, addressing the limitations of generic, "one-size-fits-all" NVD scores.
• Adoption Requires Effort and Tooling Updates: Transitioning to CVSS v4 is not a simple switch. Challenges include ensuring tool support (internal and external), understanding the updated math, and adapting internal processes, necessitating careful planning and resource allocation.
• CVSS is Part of a Broader Ecosystem: Over a third of organizations use CVSS in conjunction with other scoring systems like EPSS, SSVC, and internal models, highlighting the need for a holistic approach to vulnerability prioritization.
• The CVSS SIG is Actively Enhancing Guidance: The SIG is committed to improving documentation, examples (e.g., SSRF, XSS, CSRF), and FAQs, and is developing an "enhanced user guide" to help organizations mature their use of CVSS v4.
• Expect Changes in Scores and Processes: CVSS v4 introduces "more fidelity," "supplemental metrics," and a different calculation methodology than v3. Organizations must anticipate changes in vulnerability scores and adjust their internal processes accordingly, as it is not a direct "drop-in replacement."

About the Speaker(s)

Nick Leali is a co-chair of the CVSS Special Interest Group (SIG), a role he has held for approximately two years. His professional background includes extensive experience within Cisco, where he currently serves as an Incident Manager in Cisco PERT. Prior to this, he was involved in Cisco's third-party software management system, where he actively utilized CVSS v4 for a considerable period. Leali is also an "amateur software developer," having created a tool to assist with CVSS v4 adoption analysis, demonstrating his hands-on approach to solving practical challenges in vulnerability management. He is a passionate advocate for CVSS, consistently seeking to improve the standard and provide better guidance for its users.