A vulnerability description includes several fields, like the title and description. However, one is causing difficulties for people writing CVE (Common Vulnerability Enumeration) entries: the CVSS (Common Vulnerability Scoring System) vector. CVSS is an important field because it answers a fundamental question about the vulnerability: "How serious is it?"
A new version of CVSS, version 4.0, has recently been implemented, and it is a great occasion to review how we calculate the CVSS score.
One important thing to know about CVSS is that it describes the situation under a reasonable worst-case scenario. This also means there might be differences in the scoring between different people. At the Eclipse Foundation, we often have scoring from the reporter, the Project team, and the Eclipse Foundation Security team—we discuss and reach an agreement in the end.
Let us start with the older version, CVSS 3.1, which can be found in CVEs from 2023 or 2024.
CVSS 3.1 has the following fields:
- Attack Vector: Does the attacker need physical access to the system, a local account, or a local network (e.g., Bluetooth or the same IP subnet), or can the attack be conducted remotely?
- Attack Complexity: is the attack easy to perform with code that will work every time (low complexity), or require work and preparation, or multiple attempts (to generate a race condition, for example) (high complexity)
- Privileges Required: Does the attack require no permission at all? Low permissions (for example, a user account)? Or high permissions (for example, an administrator account)?
- User Interaction: Can the attack be run without the user's intervention? Or does it require some, like clicking on a link or installing a specific package?
- Scope: this one is more complicated. Unchanged scope means that only the attacked component is affected in the case of the attack. Most vulnerabilities we see have an "Unchanged" scope. The other option is "Changed," which happens when the attack affects other components, too. An example might be an XSS (Cross-Site Scripting) where the attack occurs against a web application, but the affected system is the user's web browser.
- Confidentiality: There is either no loss of confidentiality, low loss with either a limited amount of confidential information obtained or limited control of what is obtained, or high loss when all confidential information of a system is available to the attacker.
- Integrity: There is either no loss of integrity, a low loss with either limited or partial modification by the attacker, or a complete loss of integrity when the attacker can modify any information in the vulnerable component.
- Availability: There is either no loss of availability, limited loss when, for example, the component is working slowly, or a high availability loss in case of a complete denial of service.
You can review examples from the FIRST site: https://www.first.org/cvss/v3.0/examples.
The CVSS 4.0 https://www.first.org/cvss/v4.0/specification-document includes some changes.
Instead of the Scope parameter, it has a notion of the Subsequent system - a system other than the attacked one that might be affected by the attack. It also adds fields about the attack's impact and the urgency of remediation. CVSS 4.0 is also more modular: there is the Base metrics group that describes the unchangeable properties of the vulnerability, but there are additional metrics that can adjust the score based on a particular situation.
Let us review the main fields.
- First, the Attack Vector, Attack Complexity, and Privileges Required are the same.
- User Interaction gets more details: there might be None (no user interaction required), Passive (involuntary actions from the user who is not working with the attacker), and Active (where the user is working with the attacker—for example, placing a file in a specific place or ignored a security warning).
- Attack Requirements is a new field. None means there are no specific conditions. However, "Present" means that the attack can take place in a particular configuration; the attacker needs to control the path between the user and the vulnerable system, and so on.
- Confidentiality/Integrity/Availability fields have the same values, but now you can set them separately for the Product (the attacked system) and Subsequent (another system)
Some additional optional fields (they can have a "Not defined" value) include:
- Safety Impact - is there a safety impact of the vulnerability?
- Automatable attack - is it possible to automate the attack?
- Recovery - after a successful attack, does the system return to standard functionality?
- Value Density - Does a single attack allow control of many resources?
- Vulnerability Response Effort—How much effort does responding to the vulnerability require? Is it a trivial change in a configuration, a simple update, or does a technician have to have physical access to each affected device?
- Urgency - how urgent is it to remediate this vulnerability?
You can calculate the CVSS 4.0 score using the calculator.
The Eclipse Foundation staff is starting to use CVSS 4.0 when assigning new CVEs. If needed, we will help with the evaluation and encourage Projects to set up the Vulnerability Response Effort and Urgency fields that we find especially useful.
Contact the Eclipse Foundation Security Team if you have any questions about CVSS 4.0 and scoring!
