The Common Vulnerability Scoring System (CVSS) is a standardized framework used in the field of cybersecurity to assess the severity of vulnerabilities in computer systems, including web applications. It provides a structured and quantitative approach to evaluating the potential impact and exploitability of a vulnerability, enabling organizations to prioritize their response and allocate resources effectively.
CVSS assigns a numerical score to each vulnerability based on various factors, such as the potential impact on confidentiality, integrity, and availability of the system, as well as the ease of exploit and the level of user interaction required. The scoring system ranges from 0 to 10, with higher scores indicating more severe vulnerabilities.
To assess the severity of a vulnerability using CVSS, several metrics are considered. These metrics are divided into three groups: Base, Temporal, and Environmental. The Base metrics represent intrinsic characteristics of the vulnerability and are generally stable over time, while the Temporal and Environmental metrics provide additional context and may change over time or depending on the specific environment.
The Base metrics consist of the following elements:
1. Attack Vector (AV): This metric describes how an attacker can gain access to the vulnerable component. It considers factors such as network proximity, required privileges, and user interaction. For example, a vulnerability that can be exploited remotely over the network may have a higher score than one that requires physical access to the system.
2. Attack Complexity (AC): This metric evaluates the level of complexity required to exploit the vulnerability. It takes into account factors such as the knowledge and resources needed by an attacker. For instance, a vulnerability that can be easily exploited without specialized knowledge may have a higher score.
3. Privileges Required (PR): This metric assesses the level of privileges an attacker must possess to exploit the vulnerability. It considers factors such as the required access rights and the scope of the impact. A vulnerability that can be exploited by an unprivileged user may have a higher score.
4. User Interaction (UI): This metric determines whether the vulnerability can be exploited without any interaction from the user. It considers factors such as social engineering techniques or the need for the victim to perform specific actions. A vulnerability that can be exploited without user interaction may have a higher score.
5. Scope (S): This metric defines the extent of the impact caused by the vulnerability. It considers whether the vulnerability affects only the vulnerable component or has broader implications for the entire system. A vulnerability with a larger scope may have a higher score.
The Temporal metrics provide additional information about the vulnerability that may change over time. These metrics include:
1. Exploit Code Maturity (E): This metric reflects the current availability and maturity of exploit code for the vulnerability. It takes into account factors such as the existence of public exploits or the difficulty of developing an exploit. A vulnerability with readily available exploit code may have a higher score.
2. Remediation Level (RL): This metric represents the level of available remediation measures for the vulnerability. It considers factors such as the availability of patches or workarounds. A vulnerability with no available remediation measures may have a higher score.
3. Report Confidence (RC): This metric reflects the confidence level in the existence and impact of the vulnerability. It considers factors such as the quality and credibility of the vulnerability report. A vulnerability with a high level of confidence may have a higher score.
Finally, the Environmental metrics allow organizations to tailor the CVSS score to their specific environment. These metrics include:
1. Confidentiality Requirement (CR): This metric represents the importance of confidentiality in the affected system. It considers factors such as the sensitivity of the data or the regulatory requirements. A vulnerability that compromises highly confidential information may have a higher score.
2. Integrity Requirement (IR): This metric represents the importance of integrity in the affected system. It considers factors such as the criticality of the data or the impact of unauthorized modifications. A vulnerability that allows unauthorized changes to critical data may have a higher score.
3. Availability Requirement (AR): This metric represents the importance of availability in the affected system. It considers factors such as the impact of service disruptions or the requirements for continuous operation. A vulnerability that leads to a significant loss of availability may have a higher score.
By considering these metrics, CVSS provides a standardized and objective way to assess the severity of vulnerabilities. Organizations can use the CVSS score to prioritize their response, focusing on vulnerabilities with higher scores and allocating resources accordingly. Additionally, CVSS can help security teams communicate the severity of vulnerabilities to stakeholders in a clear and consistent manner.
The Common Vulnerability Scoring System (CVSS) is a standardized framework used to assess the severity of vulnerabilities in computer systems. It assigns a numerical score based on various metrics, including the potential impact, exploitability, and environmental factors. By using CVSS, organizations can prioritize their response and allocate resources effectively to address the most severe vulnerabilities.
Other recent questions and answers regarding EITC/IS/WASF Web Applications Security Fundamentals:
- Does implementation of Do Not Track (DNT) in web browsers protect against fingerprinting?
- Does HTTP Strict Transport Security (HSTS) help to protect against protocol downgrade attacks?
- How does the DNS rebinding attack work?
- Do stored XSS attacks occur when a malicious script is included in a request to a web application and then sent back to the user?
- Is the SSL/TLS protocol used to establish an encrypted connection in HTTPS?
- What are fetch metadata request headers and how can they be used to differentiate between same origin and cross-site requests?
- How do trusted types reduce the attack surface of web applications and simplify security reviews?
- What is the purpose of the default policy in trusted types and how can it be used to identify insecure string assignments?
- What is the process for creating a trusted types object using the trusted types API?
- How does the trusted types directive in a content security policy help mitigate DOM-based cross-site scripting (XSS) vulnerabilities?
View more questions and answers in EITC/IS/WASF Web Applications Security Fundamentals

