Also available in PDF format (408KiB).
The Common Vulnerability Scoring System (CVSS) is an open framework forcommunicating the characteristics and severity of software vulnerabilities. CVSSconsists of three metric groups: Base, Temporal, and Environmental. The Basegroup represents the intrinsic qualities of a vulnerability that are constantover time and across user environments, the Temporal 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. The Base metrics produce a score ranging from 0 to 10, whichcan then be modified by scoring the Temporal and Environmental metrics. A CVSSscore is also represented as a vector string, a compressed textualrepresentation of the values used to derive the score. This document providesthe official specification for CVSS version 3.1.
The most current CVSS resources can be found at https://www.first.org/cvss/
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 right 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 scores conforms to the guidelines described in thisdocument and provides both the score and the scoring vector so others canunderstand how the score was derived.
This guide supplements the Common Vulnerability Scoring System (CVSS) version3.1 Specification Document with additional information including significantchanges from CVSS version 3.0, additional scoring guidance, and scoring rubrics.
Since its initial release in 2004, CVSS has enjoyed widespread adoption. InSeptember 2007, CVSS v2.0 was adopted as part of the Payment Card Industry DataSecurity Standard (PCI DSS). In order to comply with PCI DSS, merchantsprocessing credit cards must demonstrate that none of their computing systemshas a vulnerability with a CVSS score greater than or equal to 4.0. In 2007, theNational Institute of Standards and Technology (NIST) included CVSS v2.0 as partof its Security Content Automation Protocol (SCAP).1 In March 2016, CVSS v3.0was formally adopted as an international standard for scoring vulnerabilities(ITU-T X.1521).2
Changes between CVSS versions 3.0 and 3.1 focus on clarifying and improving theexisting standard without introducing new metrics or metric values, and withoutmaking major changes to existing formulas. The significant changes are explainedbelow.
2.1. CVSS Measures Severity, not Risk
The CVSS Specification Document has been updated to emphasize and clarify thefact that CVSS is designed to measure the severity of a vulnerability and shouldnot be used alone to assess risk.
Concerns have been raised that the CVSS Base Score is being used in situationswhere a comprehensive assessment of risk is more appropriate. The CVSS v3.1Specification Document now clearly states that the CVSS Base Score representsonly the intrinsic characteristics of a vulnerability which are constant overtime and across user environments. The CVSS Base Score should be supplementedwith a contextual analysis of the environment, and with attributes that maychange over time by leveraging CVSS Temporal and Environmental Metrics. Moreappropriately, a comprehensive risk assessment system should be employed thatconsiders more factors than simply the CVSS Base Score. Such systems typicallyalso consider factors outside the scope of CVSS such as exposure and threat.
2.2. Changes to Attack Vector and Modified Attack Vector
CVSS v3.0 described the metric values for Attack Vector (AV) using references tothe Open Systems Interconnection (OSI) model. While technically accurate, thiswording may be unfamiliar to the general CVSS provider and consumer population,so has been reworded.
The Attack Vector (AV) metric value Adjacent (A) has a limited usage, as definedin CVSS v3.0. Ambiguity over the attack vector for logically adjacent or trustednetworks (MPLS, VPNs, etc.) is addressed by expanding the definition of Adjacentto include these limited access networks.
Section 3.6 contains new guidance on using the Modified Attack VectorEnvironmental Metric when resources are exclusively behind a firewall.
2.3. Changes to Scoring Guidance
The CVSS Specification Document and User Guide have been updated with additionalguidance to help CVSS analysts produce scores that are consistent and defensibleacross various situations that were previously considered ambiguous. A samplingof the new scoring guidance is listed below.
2.3.1. Scoring Should Assume Detailed Knowledge
The CVSS Specification Document has been updated to clarify that, when scoringBase Metrics, it should be assumed that the attacker has advanced knowledge ofthe weaknesses of the target system, including general configuration and defaultdefense mechanisms (e.g., built-in firewalls, rate limits, or traffic policing).
Refer to Section 2.1 of the CVSS v3.1 Specification Document for moreinformation.
2.3.2. Score Based on Privileges Gained, not Attained
Additional text has been added to Section 2.3 of the Specification Document toclarify that only the increase in access, privileges gained, or other negativeoutcome as a result of successful exploitation should be considered when scoringthe impact metrics of a vulnerability.
When scoring impact, CVSS analysts should consider the privileges the attackerhas prior to exploiting a vulnerability and compare those to the privileges theyhave after exploitation. The change in privileges is then captured in the ImpactMetrics, i.e., Confidentiality, Integrity and Availability.
Finally, when scoring a delta change in Impact Metric, the final impact shouldbe used.
2.3.3. Assume Vulnerable Configurations
The explanation of Attack Complexity in CVSS v3.0 considers “the presence ofcertain system configuration settings”. This text has been removed from CVSSv3.1. If a specific configuration is required for an attack to succeed, thevulnerable component should be scored assuming it is in that configuration,providing it is a reasonable configuration. Unreasonable configurations arethose that deliberately place the target in a vulnerable state, e.g., bydisabling security features, or that conflict with documented configurationguidance, e.g., by using a non-default configuration that a product vendorexplicitly states should never be used.
2.3.4. Scope Explanation Reworded
The explanation of Scope in the Specification Document has been rewritten to beclearer, along with the concepts of Vulnerable Component and Impacted Component.Section 3.5 of the User Guide contains additional information and severalexamples.
2.3.5. Scoring Vulnerabilities in Software Libraries (and Similar)
New guidance explains how to score the impact of a vulnerability in a library.Refer to Section 3.7 for more information.
2.3.6. Multiple CVSS Base Scores
New guidance explicitly allows multiple CVSS Base Scores to be generated for avulnerability that affects multiple product versions, platforms, and/oroperating systems. Refer to Section 3.8 for more information.
2.3.7. Guidance for Using Environmental Security Requirements Metrics
The Environmental Metric Group includes three Security Requirement metrics:Confidentiality Requirement (CR), Integrity Requirement (IR), and AvailabilityRequirement (AR). Section 3.11 contains new guidance and examples explaining howthese metrics can be used.
2.4. Guidance for Scoring Attack Vector
New guidance on scoring Attack Vector is provided in Section 3.10.
2.5. The CVSS Extensions Framework
Section 3.9 defines a standard method of extending CVSS to include additionalmetrics and metric groups while retaining the official Base, Temporal, andEnvironmental Metrics. The additional metrics allow industry sectors such asprivacy, safety, automotive, healthcare, etc., to score factors that are outsidethe core CVSS standard.
2.6. Formula Changes
The formulas used to calculate Base, Temporal and Environmental scores havealtered in the following ways.
2.6.1. General Formula Restructuring
The formulas have been restructured to make them clearer and remove ambiguitycaused by defining Impact sub-score for different purposes. These are purelyclarifications and do not alter the scoring.
2.6.2. Roundup Function Redefinition
The “Round up” function in CVSS v3.0 has been renamed Roundup and is nowdefined more precisely to minimize the possibility of implementations generatingdifferent scores due to small floating-point inaccuracies. This can happen dueto differences in floating point arithmetic between different languages andhardware platforms. Appendix A in the Specification Document describes theproblem in detail and suggests solutions.
As an example of the scoring differences this redefinition may cause, the CVSSv3.1 version of the reference JavaScript CVSS calculator on FIRST's websitescores the following vulnerabilities differently compared to v3.0:
- The Temporal Score for all vulnerabilities which have a Base Score of 2.5,5.0 or 10.0, Exploit Code Maturity (E) of High (H), Remediation Level (RL)of Unavailable (U) and Report Confidence (RC) of Unknown (U) is 0.1 lower inCVSS v3.1 than for 3.0. For example, the following metric combination has aTemporal Score of 4.7 in CVSS v3.0, but 4.6 in v3.1:
CVSS:3.1/AV:P/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:H/E:H/RL:U/RC:U
Some combinations of metrics have Environmental Scores that differ whenscored with CVSS v3.1 rather than v3.0. This is due to a combination of theredefinition of Roundup and the change to the ModifiedImpact sub-formulaexplained in the next section. Less than 7% of metric combinations are 0.1higher in CVSS v3.1 than v3.0, and less than 1% are 0.1 lower. NoEnvironmental Scores differ by more than 0.1.
Other implementations of the CVSS formulas may see different scoring changesbetween CVSS v3.0 and v3.1 if they previously generated different CVSS v3.0scores due to the problems that the CVSS v3.1 formula changes are intendedto fix.
2.6.3. Change to ModifiedImpact Sub-formula in Environmental Metric Group
In CVSS v3.0, certain sets of Environmental metrics have the counter-intuitiveproperty that changing the value of a Security Requirement or Modified Impactmetric to a value that should produce a higher Environmental Score results in alower score. The problem occurs only if Modified Scope is Changed and at leastone of the Security Requirement metrics is High. As an example, the followingvulnerability has an Environmental Score of 5.6:
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H/E:U/RL:T/RC:U/CR:L/IR:L/AR:H/MAV:P/MAC:H/MPR:H/MUI:R/MS:C/MC:L/MI:H/MA:H
Raising Modified Confidentiality (MC) from Low to High should result in an equalor higher score, but results in a decreased Environmental Score of 5.5:
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H/E:U/RL:T/RC:U/CR:L/IR:L/AR:H/MAV:P/MAC:H/MPR:H/MUI:R/MS:C/MC:H/MI:H/MA:H
The root cause is the part of the ModifiedImpact formula that is used whenModified Scope is Changed, and specifically the term 3.25 × (MISS - 0.02)15.MISS is the Modified Impact Sub-Score. This lowers the highest EnvironmentalScores while making no appreciable difference to low Environmental Scores.However, as the highest possible values of MISS are reached, this term increasesmore quickly than the first term of the sub-formula, resulting in the value ofthe sub-formula decreasing as MISS increases.
Various potential fixes were examined, with the goal of minimizing the number ofsets of metrics that would result in different Environmental Scores between CVSSv3.0 and v3.1. It was found that reducing the effect of MISS by multiplying itwith a constant worked, but altered more scores than a similar approach thatalso reduced the outer exponent from 15 to 13. The value of the MISS constantthat is new in CVSS v3.1 is the largest value that fixes all instances of theproblem, and being the largest value means it results in the fewest changes tounaffected scores.
2.7. Update to the Version Identifier in the Vector String
The Vector String has been updated so that it begins with CVSS:3.1 rather thanCVSS:3.0. Although no other changes have been made to the Vector String, CVSSv3.1 contains changes to the definition of some of the metric values and to theformulas, so it is important to correctly indicate the version of CVSS.
Below are a number of recommendations for analysts when scoring vulnerabilitieswith CVSS v3.1.
3.1. CVSS Scoring in the Exploit Life Cycle
When understanding when to score the impact of vulnerabilities, analysts shouldconstrain impacts to a reasonable final impact which they are confident anattacker is able to achieve. Ability to cause this impact should be supported bythe Exploitability sub-score as a minimum, but may also include details from thevulnerability’s description. For example, consider the following twovulnerabilities.
In vulnerability 1, a remote, unauthenticated attacker can send a trivial,crafted request to a web server which causes the web server to disclose theplaintext password of the root (administrator) account. The analyst only knowsfrom the Exploitability sub-score metrics and the vulnerability description thatthe attacker has access to send a crafted request to the web server in order toexploit the vulnerability. Impact should stop there; while an attacker may beable to use these credentials to later execute code as the administrator, it isnot known that the attacker has access to a login prompt or method to executecommands with those credentials. Gaining access to this password represents adirect, serious loss of Confidentiality only:
Base Score: 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
In vulnerability 2, a local, low-privileged user can send a trivial, craftedrequest to the operating system which causes it to disclose the plaintextpassword of the root (administrator) account. The analyst knows from theExploitability sub-score metrics and the vulnerability description that theattacker has access to the operating system, and can log in as a local, lowprivileged attacker. Gaining access to this password represents a direct,serious loss of Confidentiality, Integrity, and Availability because the analystcan reasonably issue commands as the root / administrator account (assume thatthe attacker could log out from their own account and log back in as root):
Base Score: 7.8 CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
3.2. Confidentiality and Integrity, Versus Availability Impacts
The Confidentiality and Integrity metrics refer to impacts that affect thedata used by the service. For example, web content that has been maliciouslyaltered, or system files that have been stolen. The Availability impact metricrefers to the operation of the service. That is, the Availability metricspeaks to the performance and operation of the service itself – not theavailability of the data. Consider a vulnerability in an Internet service suchas web, email, or DNS that allows an attacker to modify or delete all web filesin a directory. The only impact is to Integrity, not Availability, as the webservice is still functioning – it just happens to be serving back alteredcontent.
3.3. Local Vulnerabilities Exploited by Remote Attackers
Guidance concerning Local attacks was improved in CVSS v3.0 by clarifying thedefinitions of the Network and Adjacent values of the Attack Vector metric.Specifically, analysts should only score for Network or Adjacent when avulnerability is bound to the network stack. Vulnerabilities which require userinteraction to download or receive malicious content (which could also bedelivered locally, e.g., via USB drives) should be scored as Local.
For example, a document parsing vulnerability, which does not rely on thenetwork in order to be exploited, should typically be scored with the Localvalue, regardless of the method used to distribute such a malicious document(e.g., it could be a link to a web site, or via a USB flash drive).
3.4. Vulnerability Chaining
CVSS is designed to classify and rate individual vulnerabilities. However, it isimportant to support the needs of the vulnerability analysis community byaccommodating situations where multiple vulnerabilities are exploited in thecourse of a single attack to compromise a host or application. The scoring ofmultiple vulnerabilities in this manner is termed Vulnerability Chaining. Notethat this is not a formal metric, but is included as guidance for analysts whenscoring these kinds of attacks.
When scoring a chain of vulnerabilities, it is the responsibility of the analystto identify which vulnerabilities are combined to form the chained score. Theanalyst should list the distinct vulnerabilities and their scores, along withthe chained score. For example, this may be communicated within a vulnerabilitydisclosure notice posted on a web page.
In addition, the analyst may include other types of related vulnerabilities thatcould be chained with the vulnerabilities being scored. Specifically, theanalyst may list generic types (or classes) of related vulnerabilities that areoften chained together, or provide further descriptions of requiredpreconditions that must exist. For example, one might describe how certain kindsof SQL Injection vulnerabilities are precursors to a cross-site scripting (XSS)attack, or how a particular kind of buffer overflow would grant localprivileges. Listing the generic types or classes of vulnerabilities provides theminimum information necessary to warn other users, without potentially informingattackers about new exploit opportunities.
Alternatively, the analyst may identify (in the form of a machine readable andparsable list of vulnerabilities as CVE IDs or CWEs), a complete list ofspecific related vulnerabilities that are known to be (or are very likely to be)chained to one or more of the chained vulnerabilities being scored in order toexploit an IT system. In the event that a vulnerability can be exploited onlyafter other preconditions are met (such as first exploiting anothervulnerability), it is acceptable to combine two or more CVSS scores to describethe chain of vulnerabilities by scoring for the least-restrictive Exploitabilitysub-score metrics and scoring for the most-impactful Impact sub-score metrics.The following example uses the Exploitability, Scope, and Impact sub-scores todescribe the chain.
Vulnerability A is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. It requires alocal, low-privileged user in order to exploit.
Vulnerability B is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L. It provides anunprivileged, remote attacker the ability to execute code on a system with Lowimpacts if a local user interacts to complete the attack.
Given A and B, chain C could be described as the chain of B → A,
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H which combines the Exploitabilityof B, the scope is unchanged in both cases, and the Impact of A, because if onecan exploit B and gain the code execution as a local user from it, then one hassatisfied the prerequisite to subsequently launch A causing an impact fromvulnerability A.
3.5. Scope, Vulnerable Component, and Impacted Component
When a vulnerability in a component governed by one security authority is ableto affect resources governed by another security authority, a Scope change hasoccurred. This typically happens either when the vulnerable component andimpacted component are part of different systems (physical or logical) governedby different security authorities; or when an artificial boundary has been madeto logically separate vulnerable and impacted components for security reasons(e.g., when executing a process in sandbox). When a security boundary mechanismseparating components is circumvented due to a vulnerability and this causes asecurity impact outside of the security scope of the vulnerable component, aScope change has occurred. In this case, the vulnerability usually resides inthe component that implements or controls the security boundary since thevulnerability restricted to the component alone would not cause an impactoutside of its scope, assuming the security boundary works as expected.
The following example vulnerabilities look at different aspects of scoringScope:
A vulnerability in a virtual machine that enables an attacker to read and/ordelete files on the host operating system (perhaps even its own virtualmachine) is considered a Scope change. In this example, there are twoseparate security authorities: one that defines and enforces access controlfor the virtual machine and its users, and another that defines and enforcesaccess control for the host system within which the virtual machine runs.
A violation of a security boundary between microprocessor privilege levelsshould be considered when scoring vulnerabilities using CVSS. User spaceprograms’ capabilities running in lower privilege levels are typicallylimited in what instructions they can run and what registers they can writeto even when running under operating system administrator privileges. Avulnerability that allows a program running in a lower privilege level tobreak out and run arbitrary code in a higher privilege level should beconsidered a Scope change.
The security boundary between secure enclaves integrated in microprocessorsand the rest of operating system processes, including the operating systemkernel itself, should be considered when scoring vulnerabilities using CVSS.A vulnerability that allows other processes to impact the confidentiality,integrity or availability of data or code in a secure enclave should beconsidered a Scope change.
A Scope change occurs when a vulnerability in a web application impacts userclients, e.g., web browsers. Common vulnerabilities of this type includecross-site scripting and URL redirection. The vulnerability is in the webapplication, but there is an impact to the data/behavior of the victimusers’ web browsers, which are within a different security scope.
In a distributed environment, a vulnerability in a component providingconnectivity, protection, or authentication services to components in adifferent security authority should be scored as a Scope change if asuccessful attack impacts these other components. For example, avulnerability in a component such as a router, firewall, or authenticationmanager that affects the primary availability of one or more downstreamcomponents should be scored as a Scope change. However, if a successfulattack either does not affect at all, or causes only negligible impact tocomponents in a different security authority, the vulnerability should bescored as Scope unchanged. For example, a vulnerability in a componentdesigned to be deployed as part of a larger fault-tolerant topology shouldnot be scored with a changed Scope if the fault-tolerance means a successfulattack does not affect components in different security authorities. Anyeffect on additional services provided by the vulnerable component isconsidered a secondary impact and not a scope change.
A vulnerability in a simple Portable Document Format (PDF) reader thatallows an attacker to compromise other files on the same operating systemwhen a victim opens a malicious PDF document is scored as Scope unchanged.This assumes the PDF reader does not have any authorization functionalitythat would be considered a separate security authority from the underlyingoperating system.
A SQL injection vulnerability in a web application is not usually considereda Scope change assuming the credentials are shared between web applicationand impacted SQL database, and therefore they are part of the same securityscope.
A vulnerability that crashes a web server or SSH server is not considered aScope change since the impact is limited only to the service provided by theaffected server. The impact on users is secondary and is not considered aScope change as users are not considered components.
A vulnerability that permits an attacker to exhaust a shared systemresource, such as filling up a file system, should not be considered a Scopechange as the attacker is still acting under the usual capabilities of theapplication and not breaching any security boundary.
By exploiting a vulnerability in an application that allows users restrictedaccess to resources shared with other components across multiple securityscopes (e.g., operating system resources such as system files), an attackercan access resources that they should not be able to access. Since there isalready a valid path across the trust boundary, there is no Scope change.
A vulnerability in an application that implements its own security authoritywhich allows attackers to affect resources outside its security scope isscored as a Scope change. This assumes the application provides no featuresfor users to access resources governed by a higher-level security authorityshared with other components across multiple security scopes (e.g., theresources of the underlying operating system). One example would be a webapplication that allows users to read and modify web pages and files onlyunder the web application’s installation paths, and provides no feature forusers to interact beyond these paths. A vulnerability in this applicationallowing a malicious user to access operating system files unrelated to thisapplication is considered a Scope change.
3.6. Vulnerable Components Protected by a Firewall
If a vulnerability is scored with an Attack Vector (AV) of Network (N) and theanalyst has high confidence that the vulnerable component is deployed on asecure network unavailable from the Internet, Modified Attack Vector (MAV) maybe scored as Adjacent, reducing the overall CVSS v3.1 score.
Example: MySQL Stored SQL Injection (CVE‑2013‑0375)
Base Score: 6.4 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
Environmental Score: 5.4 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N/MAV:A
3.7. Scoring Vulnerabilities in Software Libraries (and Similar)
When scoring the impact of a vulnerability in a library, independent of anyadopting program or implementation, the analyst will often be unable to takeinto account the ways in which the library might be used. While specificproducts using the library should generate CVSS scores specific to how they usethe library, scoring the library itself requires assumptions to be made. Theanalyst should score for the reasonable worst-case implementation scenario. Whenpossible, the CVSS information should detail these assumptions.
For example, a library that performs image conversion would reasonably be usedby programs that accept images from untrusted sources over a network. In thereasonable worst-case, it would pass them to the library without checking thevalidity of the images. As such, an analyst scoring a vulnerability in thelibrary that relates to the incoming data should assume an Attack Vector (AV) ofNetwork (N), but explain this assumption in the summary of the vulnerability. Ifthe library might run with normal privileges, having lower impact on theembedding implementation, or with high privileges, increasing the impacts, theanalyst should assume high privileges while scoring the vulnerability in thelibrary.
When scoring a vulnerability in a given implementation using the impactedlibrary, the score must be re-calculated for that specific implementation. Forexample, if an implementation embeds the vulnerable library mentioned in theprevious example, but only operates on local files, the Attack Vector (AV) wouldbe Local (L). If the implementation that embeds this library does not invoke anyof the faulty functions or does not support the mode that triggers thatvulnerability, it would have no interface or attack vector to exploit thevulnerability. Thus, that vulnerability in the embedded library would have noimpact on that implementation, resulting in a score for the given implementationof 0.
3.8. Multiple CVSS Base Scores
It is common for a vulnerability to be present on multiple product versions,platforms, and/or operating systems. In some circ*mstances, the Base metrics maydiffer on different product versions, platforms, and/or operating systems. Forexample, a hypothetical vulnerability is applicable to multiple operatingsystems produced by the same vendor. The Attack Complexity (AC) of thisvulnerability on a legacy operating system is Low (L). However, a neweroperating system has new inherent protection capabilities that change the AttackComplexity to High (H). This variance ultimately leads to different Base Scoresfor the same vulnerability on the two operating systems.
It is acceptable to score and publish multiple Base Scores for a singlevulnerability provided each has additional language outlining the specificproduct versions, platforms, and/or operating systems that are relevant to thescore. Values for all Base Score attributes (not only a pre-calculated BaseScore) must be supplied for each affected product version, platform, and/oroperating system using a standard format. In situations where multiple BaseScores are applicable but only a single score is provided, the highest BaseScore must be utilized.
3.9. CVSS Extensions Framework
Opportunities exist to leverage the core foundation of CVSS for additionalscoring efforts. For example, a proposal was presented to the CVSS SpecialInterest Group (SIG) to incorporate privacy into CVSS by overlaying combinationsof CVSS Base and Environmental metrics to derive a Privacy Impact.
The following guidelines define a standard method of extending CVSS to includeadditional metrics and metric groups while retaining the official Base,Temporal, and Environmental Metrics. The additional metrics allow industrysectors such as privacy, safety, automotive, healthcare, etc., to score factorsthat are outside the core CVSS standard.
3.9.1. Guidelines
Formulas, constants or definitions of existing CVSS Base, Temporal, orEnvironmental Metrics must not be modified. If a change to an existing itemis desired, create a new metric group with a new name and work on it asdesired.
New metrics must not be added to existing metric groups, but must be addedto new metric groups. New metric groups can be based on existing metricgroups.
New metrics can be based on sub-formulas in the standard, such as theExploitability sub-score, but these could change, be removed or be replacedin future revisions of the standard, and so absolute values should not berelied upon.
New metric groups can optionally have a score. If they do, the score must bebetween 0.0 and 10.0, with 10.0 being the most severe. The score must bebased on adjusting the Base Score and/or Environmental and Temporal scores,similar to how Environmental/Temporal scores adjust the Base Score toproduce the final score.
The CVSS SIG does not officially approve extensions, but rather acts as aconsulting body, similar to IETF3. The CVSS SIG welcomes and encouragesinnovation, but has an interest in maintaining consistency across allproposed extensions.
The list of validated extensions will be listed on the first.org web site,similar to IANA4.
Mandatory Fields: Name, Description, External Authoritative Web Page
Optional Fields: JSON Schema, XML Schema, JavaScript Calculator
3.9.2. Suggested Vector String Format
CVSS Extension vector strings must be listed separately, utilizing the followingformat:
CVSS:3.1/AV:x/AC:x/PR:x/UI:x/S:x/C:x/I:x/A:x
EXT:1.0/NEW1:VAL1/NEW2:VAL2
where:
EXT:n.n is a unique extension identifier and major.minor version number
NEWn is a unique attribute of the extension for each new metric
VALn is a unique value for the attribute for each new metric value
3.10. Attack Vector Considerations
When scoring Attack Vector, use Adjacent or Network (as appropriate), when anetwork connection is required for an attack to succeed, even if the attack isnot launched over a network. For example, a local attacker may be able to tricka vulnerable, privileged, local program into sending sensitive data to a serverof the attacker’s choosing over a network. As a network connection is requiredto gather the sensitive data this is scored with an Attack Vector of Network.
Vulnerabilities where malicious data is received over a network by onecomponent, then passed to a separate component with a vulnerability should bescored with an Attack Vector of Local. An example is a web browser thatdownloads a malicious office document, saves it to disk, and then starts avulnerable office application which reads the saved file.
In cases where the vulnerable functionality is part of the component thatreceives the malicious data, Attack Vector should be scored as Network. Anexample is a web browser with a vulnerability in the browser itself, or abrowser plugin or extension, that triggers when the malicious data is received.
3.11. Security Requirements
The Security Requirement metrics are part of the Environmental Metric Group andmodify the weighting that the modified impact metrics have on the overallEnvironmental Score. This section provides guidance on selecting appropriatemetric values for these based on the characteristics of a specific environment.The examples are simplified to illustrate the concepts.
3.11.1. Confidentiality Requirement (CR)
The Confidentiality Requirement of a system should be based on theclassification level of the data that is stored or used by the user and/orapplications running on the target system. Encryption of the data at rest onthis device should also be taken into consideration when establishing theConfidentiality Requirement. Data that passes through a device without beingconsumed or processed (e.g., a switch or firewall) should not be taken intoconsideration when assessing this attribute. See below for examples.
Note: The volume of data may influence the value of the attribute, but shouldnot have as much impact as the classification (i.e., type) of data that is beingstored or used.
A device that stores data classified at the highest level should have thisattribute rated as High. However, if the sensitive data is encrypted atrest, this attribute may be rated Medium.
A device that stores data classified as non-public but not as high as thehighest level should have this attribute rated as Medium. However, if thesensitive data is encrypted at rest, this attribute can be rated Low.
A device that stores data that can be openly shared publicly should havethis attribute rated as Low.
Network equipment such as a router, switch, or firewall will generally berated as Medium due strictly to the sensitivity of information such asrouting tables, etc.
Any system that stores login credentials without encryption should have thisattribute rated as High. This includes service accounts and credentialsembedded into scripts or source code.
3.11.2. Integrity Requirement (IR)
The Integrity Requirements of a system focus on the importance of the accuracyof the data it stores or uses. Data that passes through a device without beingconsumed or processed (e.g., a switch or firewall) should not be taken intoconsideration when assessing this attribute. The use of encryption on the dataat rest should not be taken into consideration for this attribute. See belowfor examples:
Devices that contain monetary transactional data and/or personallyidentifiable information (PII) should be rated High.
Devices that contain data directly used to make business or risk managementdecisions should be rated at a minimum of Medium. As the severity of thedecisions increase, so should the Integrity Requirement rating.
Devices that contain data directly used to make health decisions should berated High.
Network equipment such as a router or switch will generally be rated atleast Medium due strictly to the sensitivity of information such asforwarding tables, etc.
Firewalls should be rated as High due to the sensitivity of the rule set.
3.11.3. Availability Requirement (AR)
The Availability Requirement of a system should be based on the uptimerequirements and redundancy of the device or the applications hosted by thedevice. Devices that are part of redundant clusters will have lower AvailabilityRequirements. See below for examples:
Devices without full capacity redundancy that are rated with recoveryrequirements less than 24 hours should be rated High.
Devices without full capacity redundancy that are rated with recoveryrequirements between 1-5 days should be rated Medium.
Devices with recovery requirements of more than 5 days should be rated Low.
Clustered devices and/or those with full capacity redundancy should be ratedas Low.
Devices that are required to have rapid response times for transactionalpurposes based on regulatory requirements, should be rated High.
Affected: An impacted component is affected by a vulnerability if avulnerability in a vulnerable component is exploitable in a way that causes anegative impact to the Confidentiality, Integrity, and/or Availability of theimpacted component.
Authority: A computing container that grants and manages privileges toresources. Examples of authorities include a database application, an operatingsystem, and a sandbox environment.
Chained Score: The Base Score produced by scoring two or more chainedvulnerabilities.
Chained Vulnerabilities: See Vulnerability Chaining.
Component: Refers to either a hardware or software component.
Hardware Component: A physical computing device.
Software Component: A software program or module that contains computerinstructions to be executed, e.g., an operating system, Internetapplication, or device driver.
Exploitable: A weakness or flaw in a component is exploitable if itenables the component to be manipulated in an unintended or unexpected way by anattacker to negatively impact Confidentiality, Integrity, and/or Availability.
Impacted Component: The component that suffers the consequence of theexploited vulnerability. It can either be the same component as the vulnerablecomponent, or, if a scope changed has occurred, a different one.
Privileges: A collection of rights (typically read, write and execute)granted to a user or user process which defines access to computing resources.
Reasonable: An action, expectation, or outcome that most informed and awarepeople would consider just, rational, appropriate, ordinary or usual in thecirc*mstances.
Resources: A software or network object that is accessed, modified, orconsumed by a computing device, e.g., computer files, memory, CPU cycles, ornetwork bandwidth.
Scope: The collection of privileges defined and managed by an authorizationauthority when granting access to computing resources.
Successful Attack: A successful attack (or successful exploit of avulnerability) is a situation where an attacker causes any negative impact toConfidentiality, Integrity, and/or Availability by leveraging a weakness in thevulnerable component.
Vulnerability: A weakness or flaw in the functional behavior of a vulnerablecomputational component (software or hardware) that can be exploited, resultingin a negative impact to the Confidentiality, Integrity, and/or Availability ofan impacted component.
Vulnerability Chaining: The sequential exploit of multiple vulnerabilitiesin order to attack an IT system, where one or more exploits at the end of thechain require the successful completion of prior exploits in order to beexploited. See also the definition available athttps://cwe.mitre.org/documents/glossary/#Chain.
Vulnerable: A component is vulnerable if it contains a weakness or flawthat can be exploited, given the necessary conditions and/or exposure.
Vulnerable Component: The software (or hardware) component that bears thevulnerability, and that would be patched.
Weakness: An error in software or hardware implementation, code, design, orarchitecture that, depending on exposure, could be exploited by an attacker.
The scoring rubrics are an aid to scoring vulnerabilities by supplementing themetric definitions in the Specification Document.
Diagram 1: Attack Vector Rubric
Diagram 2: Attack Complexity Rubric
Diagram 3: User Interaction Rubric
Diagram 4: Privileges Required Rubric
Diagram 5: Scope Rubric
Note, if a Scope change has not occurred, Confidentiality, Integrity andAvailability impacts reflect consequence to the vulnerable component, otherwise they reflect consequence to the component that suffers the greater impact.
Diagram 6: Confidentiality Impact Rubric
Diagram 7: Integrity Impact Rubric
Diagram 8: Availability Impact Rubric
See https://scap.nist.gov/.↩
The Internet Engineering Task Force (https://www.ietf.org/)↩
Internet Assigned Numbers Authority (https://www.iana.org/)↩
