# Helping CNAs Generate CVSS Scores Faster and More Confidently Using XAI
## Appendix A Common Vulnerability Scoring System  
The Common Vulnerability Scoring System has undergone multiple revisions since its initial release in 2005:  
1. CVSSv1: The first version, introduced in 2005, included three metric groups: exploitability, impact, and severity. 2. CVSSv2: Released in 2007, this version expanded the number of metrics to incorporate environmental metrics that could be customized for specific organizations. It also introduced temporal metrics, which account for the changing nature of vulnerabilities over time. 3. CVSSv3: Introduced in 2015, CVSSv3 introduced several new metrics to enhance the accuracy and granularity of vulnerability scoring. It simplified the scoring system, improved its usability, and provided better guidance for practical application. 4. CVSSv3.1: A minor revision of CVSSv3, released in 2019, which included clarifications and improvements to the scoring system. It provided updated guidance on scoring vulnerabilities impacting containers and web applications. 5. CVSSv4: Released in 2023, CVSSv4 introduced significant changes aimed at improving the flexibility and precision of the scoring model. This version emphasized enhanced stakeholder-specific metrics and better handling of post-exploitation impact, and it introduced automated score generation features, which help users adjust scores based on evolving threat landscapes more efficiently. Each version of CVSS builds upon the previous one, incorporating feedback from the cybersecurity community and addressing new types of vulnerabilities and attack scenarios. The metrics used in the current version, v3.1, according to the MITRE specification document ([[https://www.first.org/cvss/specification-document](https://www.first.org/cvss/specification-document)]([https://www.first.org/cvss/specification-document](https://www.first.org/cvss/specification-document)), accessed on 17 May 2024), are as follows:  
* BE--Attack Vector (AV): This reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the Base Score) will be larger the more remote (logically and physically) an attacker can be in order to exploit the vulnerable component. * B--Scope (S): This captures whether a vulnerability in one vulnerable component impacts resources in components beyond its security scope. * BE--Attack Complexity (AC): This describes the conditions beyond the attacker's control that must exist in order to exploit the vulnerability. * BE--Privileges Required (PR): This describes the level of privileges an attacker must possess before successfully exploiting the vulnerability. The Base Score is greatest if no privileges are required. * BE--User Interaction (UI): This captures the requirement for a human user other than the attacker to participate in the successful compromise of the vulnerable component. This metric determines whether the vulnerability can be exploited solely at the will of the attacker or whether a separate user (or user-initiated process) must participate in some manner. The Base Score is greatest when no user interaction is required. * BE--Confidentiality Impact (CI): This measures the impact on the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones. * BE--Integrity Impact (II): This measures the impact on the integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. The Base Score is greatest when the consequence of the impacted component is highest. * BE--Availability Impact (AI): This measures the impact on the availability of the impacted component resulting from a successfully exploited vulnerability.