What is CVSS?
CVSS stands for Common Vulnerability Scoring System. It’s a numerical score – ranging from zero to ten – that represents the severity of a software vulnerability.
CVSS scores are helpful to compare the vulnerabilities found in a software system and prioritize the work needed by software developers and systems engineers to eliminate such weaknesses.
CVSS is an open framework maintained by FIRST, the Forum of Incident Response and Security Teams. It is a US-based non profit with over 500 members globally.
CVSS is very useful to provide a common way to estimate the potential impact of a vulnerability in a repeatable way, so that the vulnerability assessment can be as objective as possible. As many standardized methodology, CVSS should be complemented with a critical evaluation of the vulnerabilities in the full context where the evaluated software is used. The same vulnerability may determine a very different level of risk in different organizations.
CVSS standard versions
At Mobisec we use the latest major version, CVSS v3. It is a significant improvement over v2, adding important elements like looking at the privileges required to exploit a vulnerability and estimating the ability for an attacker to propagate across systems after exploiting that vulnerability.
CVSS is a blend of metrics
A single CVSS score – for example 6.3 – is the combination of multiple factors grouped in three families:
- Base
- Temporal
- Environmental
CVSS Base Factors
Base factors represent elements of the vulnerability itself. These characteristics don’t change over time and are not dependent on real world exploitability or other factors put in place to prevent the exploit (like an application firewall blocking an REST API call with dangerous URL parameters).
For this independence from time and environment, Base CVSS Scores are used in public databases like NIST’s NVD – the National Vulnerability Database – where you can search vulnerabilities and see their severities ranked using base scores.
CVSS Base scores are easily available and many teams use them to prioritize the work of patching software and systems. The reality is that, using just Base scores, a team may waste precious time fixing a vulnerability that is not really exploitable in the actual context. The team may be overlooking one with a lower severity score that, in the current environment, is offering a surface of attack to malicious actors.
A CVSS Base score is itself the combination of three subscore elements:
- Exploitability
- Scope
- Impact
Exploitability metrics are related to attributes of the vulnerable component, considering four scores:
- Attack Vector – this score varies based on the level of access required to exploit a vulnerability. The score will be higher for exploits that can be executed remotely (i.e. outside of a company’s network) than for exploits that require physical presence (i.e. must have access to a physical port on an appliance or access to a local network inside of a private data center).
- Attack Complexity – this score varies based on the factors outside of the attacker’s control that are required to exploit the vulnerability. The score will be higher for exploits that require additional work on the attacker’s part – such as theft of a shared secret key or a man-in-the-middle attack – than for an attack that requires no such additional effort.
- Privileges Required – this score depends on the privileges required for the attacker to conduct the exploit. A vulnerability that requires administrative privileges to exploit will have a higher score than an exploit that requires no authentication or escalated privileges on the attacker’s part.
- User Interaction – this metric depends on whether the attacker must recruit either a willing or unwitting participant in order to complete their task. The score will be higher if the attacker can operate autonomously, with no participation from a user.
Scope relates to whether a vulnerability in one component can propagate to other components. The scope score is higher if propagation is possible. Examples of high scope score include ability to access and exploit the underlying operating system after exploiting a vulnerability in a software application, or an attacker accessing a backend database after successfully exploiting a vulnerability in a web server.
Impact focuses on the actual outcome that an attacker can achieve as a result of exploiting the vulnerability in question. Impact metrics are comprised of three sub-metrics:
- Confidentiality – represents the amount of data that the attacker gains access to. The score will be higher if all data on the impacted system is accessible by the attacker, lower if no data is accessible.
- Integrity – estimates the ability of the attacker to alter or change data on the impacted system. If complete, or severely consequential modifications to data are possible, this score will be high.
- Availability – this score varies based on the loss of availability of the exploited system. The score will be high if the system is no longer accessible or usable for authorized users as a result of the attack.
CVSS Temporal Metrics
CVSS Temporal Metrics are exactly as they sound – metrics related to a vulnerability that changes over time. These metrics measure the current exploitability of the vulnerability, as well as the availability of remediating controls, such as a patch. Temporal Metrics have three subcomponents:
- Exploit Code Maturity – Until a method exists to exploit a vulnerability, it is relatively benign. As with most software, code available to conduct an exploit can mature, becoming more stable and more widely available over time. As this happens, the score on this subcomponent will increase.
- Remediation Level – When a vulnerability is first discovered, there might not be a patch or other workaround available. Over time, workarounds, temporary fixes, and ultimately official patches become available, lowering the vulnerability score as remediation is improved.
- Report Confidence – Confidence measures the level of validation demonstrating that a vulnerability is both real and exploitable.
CVSS Environmental Metrics
Environmental Metrics allow the organization to modify the Base CVSS based on Security Requirements and modifications of Base Metrics.
- Security Requirements characterize the criticality of the asset in question. Mission-critical data or assets get a higher score than less important assets. For example, a vulnerability identified in a database of all customer data would get a higher score than a vulnerability identified in a non-privileged user’s workstation.
- Modified Base Metrics – An organization may choose to modify values of the Base CVSS Metrics based on mitigations that they have put into place. For example, “air gapping” a server, or removing any external network connections, will prevent an attacker from being able to exploit a vulnerability that might otherwise be accessible remotely. The result is that the Attack Vector Base Metric is reduced in this instance.
CVSS Qualitative Ratings
It is sometimes useful, especially for purposes of discussion with less technical stakeholders, to map the 0-10 CVSS scores to qualitative ratings. FIRST maps CVSS scores to these qualitative ratings as follows:
| CVSS Score | Qualitative Rating |
| 0.0 | None |
| 0.1 – 3.9 | Low |
| 4.0 – 6.9 | Medium |
| 7.0 – 8.9 | High |
| 9.0 – 10.0 | Critical |
Limitations of CVSS
As we’ve already discussed, public databases rank vulnerabilities using Base Scores only. They represent the severity of a vulnerability, but do not reflect the risk that the vulnerability poses to your business and technical environment. In other words, CVSS severity answers the question, “Is this dangerous?”, but not, “Is this dangerous to my company?”
Given the large and growing number of vulnerabilities facing the typical organization, effective vulnerability management must account for not only the Base Score, but Temporal and Environmental Factors as well. For this part, FIRST provides the framework, but NIST can’t help you with tailoring your CVSS score to these factors, as they require first-hand knowledge of business criticality of the assets, identification of mitigating controls, use of the asset in question, and current real-world exploitability of the vulnerability. Maximizing efficiency of your security team requires a risk-based approach to vulnerability management that accounts for these factors.
The Mobisec methodology includes context-driven metrics and risk assessment since 2015. We have extensive experience in understanding our clients’ business and operational environment and supporting their decisions for prioritization and risk management.
Seeing the CVSS v3 standard including such metrics and factors validates our approach and makes us proud of our team of security experts. They are ready to help you make progress with your security posture and protect your users and your business.