JoinDetailsabout FIRST membership and joining as a full member or liaison.LearnTraining and workshop opportunities, and details about the FIRST learning platform.ParticipateRead about upcoming events, SIGs, and know what is going on.
The Common Vulnerability Scoring System (CVSS) is an open framework forcommunicating the characteristics and severity of software vulnerabilities. CVSSconsists of four metric groups: Base, Threat, Environmental, and Supplemental.The Base group represents the intrinsic qualities of a vulnerability that areconstant over time and across user environments, the Threat group reflects thecharacteristics of a vulnerability that change over time, and the Environmentalgroup represents the characteristics of a vulnerability that are unique to auser's environment. Base metric values are combined with default values thatassume the highest severity for Threat and Environmental metrics to produce ascore ranging from 0 to 10. To further refine a resulting severity score, Threatand Environmental metrics can then be amended based on applicable threatintelligence and environmental considerations. Supplemental metrics do notmodify the final score, and are used as additional insight into thecharacteristics of a vulnerability. A CVSS vector string consists of acompressed textual representation of the values used to derive the score. Thisdocument provides the official specification for CVSS version 4.0.
CVSS is owned and managed by FIRST.Org, Inc. (FIRST), a US-based non-profitorganization, whose mission is to help computer security incident response teamsacross the world. FIRST reserves the right to update CVSS and this documentperiodically at its sole discretion. While FIRST owns all rights and interest inCVSS, it licenses it to the public freely for use, subject to the conditionsbelow. Membership in FIRST is not required to use or implement CVSS. FIRST does,however, require that any individual or entity using CVSS give properattribution, where applicable, that CVSS is owned by FIRST and used bypermission. Further, FIRST requires as a condition of use that any individual orentity which publishes CVSS data conforms to the guidelines described in thisdocument and provides both the score and the vector string so others canunderstand how the score was derived.
The Common Vulnerability Scoring System (CVSS) captures the principal technicalcharacteristics of software, hardware and firmware vulnerabilities. Its outputsinclude numerical scores indicating the severity of a vulnerability relative toother vulnerabilities.
CVSS is composed of four metric groups: Base, Threat, Environmental, andSupplemental. The Base Score reflects the severity of a vulnerability accordingto its intrinsic characteristics which are constant over time and assumes thereasonable worst-case impact across different deployed environments. The ThreatMetrics adjust the severity of a vulnerability based on factors, such as theavailability of proof-of-concept code or active exploitation. The EnvironmentalMetrics further refine the resulting severity score to a specific computingenvironment. They consider factors such as the presence of mitigations in thatenvironment and the criticality attributes of the vulnerable system. Finally,the Supplemental Metrics describe and measure additional extrinsic attributes ofa vulnerability, intended to add context.
Base Metrics, and optionally Supplemental Metrics, are provided by theorganization maintaining the vulnerable system, or a third party assessment ontheir behalf. Threat and Environmental information is available to only the endconsumer. Consumers of CVSS should enrich the Base metrics with Threat andEnvironmental metric values specific to their use of the vulnerable system toproduce a score that provides a more comprehensive input to risk assessmentspecific to their organization. Consumers may use CVSS information as input toan organizational vulnerability management process that also considers factorsthat are not part of CVSS in order to rank the threats to their technologyinfrastructure and make informed remediation decisions. Such factors mayinclude, but are not limited to: regulatory requirements, number of customersimpacted, monetary losses due to a breach, life or property threatened, orreputational impacts of a potential exploited vulnerability. These factors areoutside the scope of CVSS.
The benefits of CVSS include the provisioning of a standardized vendor andplatform agnostic vulnerability scoring methodology. It is an open framework,providing transparency to the individual characteristics and methodology used toderive a score.
The Base metric group represents the intrinsic characteristics of avulnerability that are constant over time and across user environments. It iscomposed of two sets of metrics: the Exploitability metrics and the Impactmetrics.
The Threat metric group reflects the characteristics of a vulnerability relatedto threat that may change over time but not necessarily across userenvironments. For example, confirmation that the vulnerability has neither beenexploited nor has any proof-of-concept exploit code or instructions publiclyavailable will lower the resulting CVSS score. The values found in this metricgroup may change over time.
The Supplemental metric group includes metrics that provide context as well asdescribe and measure additional extrinsic attributes of a vulnerability. Theresponse to each metric within the Supplemental metric group is to be determinedby the CVSS consumer, allowing the usage of an end-user risk analysis system toapply locally significant severity to the metrics and values. No metric will,within its specification, have any impact on the final CVSS score (e.g.CVSS-BTE). Consumer organizations may then assign importance and/or effectiveimpact of each metric, or set/combination of metrics, giving them more, less, orabsolutely no effect on the categorization, prioritization, and assessment ofthe vulnerability. Metrics and values will simply convey additional extrinsiccharacteristics of the vulnerability itself.
Generally, the Base metrics are specified by vulnerability bulletin analysts,product vendors, or application vendors because they typically possess the mostaccurate information about the characteristics of a vulnerability. The Threatand Environmental metrics are specified by consumer organizations because theyare best able to assess the potential impact of a vulnerability within their owncomputing environment, at a given point in time.
Assessing CVSS metrics also produces a vector string, a textual representationof the metric values used to derive a quantitative score and qualitative ratingfor the vulnerability. This vector string is a specifically formatted textstring that contains each value assigned to each metric, and should be displayedwith the vulnerability score.
Note that all metrics should be assessed under the assumption that the attackerhas perfect knowledge of the vulnerability. That is, the analyst need notconsider the means by which the vulnerability was identified. In addition, it islikely that many different types of individuals will be assessingvulnerabilities (e.g., software vendors, vulnerability bulletin analysts,security product vendors), however, note that CVSS assessment is intended to beagnostic to the individual and their organization.
Numerical CVSS Scores have very different meanings based on the metrics used tocalculate them. Regarding prioritization, the usefulness of a numerical CVSSscore is directly proportional to the CVSS metrics leveraged to generate thatscore. Therefore, numerical CVSS scores should be labeled using nomenclaturethat communicates the metrics used in its generation.
The application of Environmental and Threat metrics is the responsibility ofthe CVSS consumer. Assessment providers such as product maintainers andother public/private entities such as the National Vulnerability Database(NVD) typically provide only the Base Scores enumerated as CVSS-B.
When assessing Base metrics, it should be assumed that the attacker has advancedknowledge of the target system, including general configuration and defaultdefense mechanisms (e.g., built-in firewalls, rate limits, traffic policing).For example, exploiting a vulnerability that results in repeatable,deterministic success should still be considered a Low value for AttackComplexity, independent of the attacker's knowledge or capabilities.Furthermore, target-specific attack mitigation (e.g., custom firewall filters,access lists) should instead be reflected in the Environmental metric scoringgroup.
Specific configurations should not impact any attribute contributing to the CVSSBase metric assessment , i.e., if a specific configuration is required for anattack to succeed, the vulnerable system should be assessed assuming it is inthat configuration.
This metric reflects the context by which vulnerability exploitation ispossible. This metric value (and consequently the resulting severity) will belarger the more remote (logically, and physically) an attacker can be in orderto exploit the vulnerable system. The assumption is that the number of potentialattackers for a vulnerability that could be exploited from across a network islarger than the number of potential attackers that could exploit a vulnerabilityrequiring physical access to a device, and therefore warrants a greaterseverity. The list of possible values is presented in Table 1.
This metric captures measurable actions that must be taken by the attacker toactively evade or circumvent existing built-in security-enhancing conditionsin order to obtain a working exploit. These are conditions whose primary purposeis to increase security and/or increase exploit engineering complexity. Avulnerability exploitable without a target-specific variable has a lowercomplexity than a vulnerability that would require non-trivial customization.This metric is meant to capture security mechanisms utilized by the vulnerablesystem, and does not relate to the amount of time or attempts it would take foran attacker to succeed, e.g. a race condition. If the attacker does not takeaction to overcome these conditions, the attack will always fail.
3a8082e126