Similar to how software bugs are triaged for a severity level, so too are security vulnerabilities as they need to be assessed for impact and risk, which aids in vulnerability management. The forum of Incident Response and Security Teams (FIRST) is an international organization of trusted security scientists and computer researchers that have received the task of creating best practices and tools for incident responses teams, as well as standardizing security methodologies and policies.
One of FIRST’s initiatives is the Special Interest Group (SIG) that is responsible for developing and maintaining the Common Vulnerability Scoring System (CVSS) specification to assist the security team to understand and prioritize the severity of a security vulnerability. 

Scoring Vulnerabilities

CVSS is known as a standard measurement system for organizations, industries and governments that need consistent and accurate vulnerability impact scores. The quantitative model of CVSS ensures accurate and repeatable measurement while allowing users to see the core vulnerability features that were used to generate the scores. CVSS is normally used to prioritize vulnerability remediation activities and to calculate vulnerabilities discovered on one’s systems.

Challenges with CVSS

Missing Applicability Context 

Vulnerability scores do not always count for the right context in which a vulnerable component is used by an organization. A Common Vulnerabilities and Exposures (CVE) system can factor in different variables when determining the score of an organization. However, in some cases others can affect the way in which a vulnerability is handled in spite of the score given to it by a CVE.

For instance, a high severity vulnerability that’s classified by the CVSS which was found in a component used for testing purposes, such as a test harness, might end up receiving little or no attention from security experts. One reason this can happen is that this component is used as a tool and is not in any way exposed in an interface accessible to the public. 

Additionally, vulnerability scores do not extend their context to account for material consequences such as when a vulnerability applies to cars, utility grids and medical devices. Each firm would need to triage and account for specific implications based on relevance to the prevalence in the specific vulnerable components for their products. 

Incorrect Scoring 

A vulnerability score includes a wide range of major characteristics and without supporting information, proper guidance and experience, mistakes can easily be made. It’s not rare to find false positives in a CVE or inaccuracies in scores that are assigned to any of the metrics groups that introduces a risk of losing trust in a CVE or creating panic for organizations.

CVSS has a score range of 0-10 that ranks severity levels starting from low to high. Inaccuracies of variables may lead to a score that maps to an inaccurate CVSS level. CVSS v3.0 can be used for evaluating and communicating security vulnerability features and their impact. The security research team takes part in discovering new vulnerabilities across ecosystems. Additionally, they work to triage CVE scores to properly showcase severities to balance the scoring inaccuracy that’s made by other authorities that issue CVEs.

An organization database provides supporting metadata beyond the CVE details for each vulnerability. The security experts curate each vulnerability with information like details about the type of vulnerability or overview of the vulnerable components that are enriched with reference links and examples to commits, fixes or other matter related to vulnerability.  

How CVSS Works 

There are three versions in CVSS’s history, beginning from its first release in 2004 to the widespread adoption of CVSS v2.0 and to the present working specification of CVSS v3.0. The specification offers a structure that standardizes the way vulnerabilities are scored in a way that’s grouped to showcase individual areas of concerns. 

The Metrics For A CVSS Score Are Allocated In Different Groups:

1. Base: Impact assessment and exploitability metrics that are not dependent on the times of a vulnerability or a user environment, such as the ease at which the vulnerability can be exploited. For instance, if a vulnerability component is denied total access because of a vulnerability, it will score a high availability impact. 

CVSS base metrics are composed of exploitability and impact metric sub-groups and assess their applicability to a software component, which may impact other components (hardware, software or networking devices).

2. Temporal: This metric accounts for situations that affect a vulnerability score. For instance, if there is a known exploit for a vulnerability the score will increase. However, if there is a patch or fix available, the score will decrease.  

The main purpose of the temporal score is to offer context according to the timing of a CVE severity. For example, if there are known public exploits for a security vulnerability, this raises the severity and criticality for the CVE because of the considerably easy access to resources for employing such attacks. 

A complete CVSS score is calculated which includes the temporal score part based on the highest risk for a value and will only be included if there is temporal risk. Consequently, any temporal score values that are assigned will keep the overall CVSS score at the lease or lower than the overall score. 

3. Environmental: This metric enables customizing the score to the impact for a user or company’s environment. For instance, if the organization values the availability that’s related to a vulnerable component, it may set a high level of availability requirement and increase the whole CVSS score. 

In conclusion, the base metrics form the bases of a CVSS vector. If temporal or environmental metrics are available, they are incorporated into the whole CVSS score.