CVSS v3.1 Specification Document (2024)

Also available in PDF format (469KiB).

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.

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 three metric groups: Base, Temporal, and Environmental. TheBase Score reflects the severity of a vulnerability according to its intrinsiccharacteristics which are constant over time and assumes the reasonable worstcase impact across different deployed environments. The Temporal Metrics adjustthe Base severity of a vulnerability based on factors that change over time,such as the availability of exploit code. The Environmental Metrics adjust theBase and Temporal severities to a specific computing environment. They considerfactors such as the presence of mitigations in that environment.

Base Scores are usually produced by the organization maintaining the vulnerableproduct, or a third party scoring on their behalf. It is typical for only theBase Metrics to be published as these do not change over time and are common toall environments. Consumers of CVSS should supplement the Base Score withTemporal and Environmental Scores specific to their use of the vulnerableproduct to produce a severity more accurate for their organizationalenvironment. Consumers may use CVSS information as input to an organizationalvulnerability management process that also considers factors that are not partof CVSS in order to rank the threats to their technology infrastructure and makeinformed remediation decisions. Such factors may include: number of customers ona product line, monetary losses due to a breach, life or property threatened, orpublic sentiment on highly publicized vulnerabilities. These are outside thescope of CVSS.

The benefits of CVSS include the provision of a standardized vendor and platformagnostic vulnerability scoring methodology. It is an open framework, providingtransparency to the individual characteristics and methodology used to derive ascore.

1.1. Metrics

CVSS is composed of three metric groups: Base, Temporal, and Environmental, eachconsisting of a set of metrics, as shown in Figure 1.

Figure 1: CVSS Metric Groups

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 Exploitability metrics reflect the ease and technical means by which thevulnerability can be exploited. That is, they represent characteristics of thething that is vulnerable, which we refer to formally as the vulnerablecomponent. The Impact metrics reflect the direct consequence of a successfulexploit, and represent the consequence to the thing that suffers the impact,which we refer to formally as the impacted component.

While the vulnerable component is typically a software application, module,driver, etc. (or possibly a hardware device), the impacted component could be asoftware application, a hardware device or a network resource. This potentialfor measuring the impact of a vulnerability other than the vulnerable component,was a key feature introduced with CVSS v3.0. This property is captured by theScope metric, discussed later.

The Temporal metric group reflects the characteristics of a vulnerability thatmay change over time but not across user environments. For example, the presenceof a simple-to-use exploit kit would increase the CVSS score, while the creationof an official patch would decrease it.

The Environmental metric group represents the characteristics of a vulnerabilitythat are relevant and unique to a particular user’s environment. Considerationsinclude the presence of security controls which may mitigate some or allconsequences of a successful attack, and the relative importance of a vulnerablesystem within a technology infrastructure.

Each of these metrics are discussed in further detail below. The User Guidecontains scoring rubrics for the Base Metrics that may be useful when scoring.

1.2. Scoring

When the Base metrics are assigned values by an analyst, the Base equationcomputes a score ranging from 0.0 to 10.0 as illustrated in Figure 2.

Figure 2: CVSS Metrics and Equations

Specifically, the Base equation is derived from two sub equations: theExploitability sub-score equation, and the Impact sub-score equation. TheExploitability sub-score equation is derived from the Base Exploitabilitymetrics, while the Impact sub-score equation is derived from the Base Impactmetrics.

The Base Score can then be refined by scoring the Temporal and Environmentalmetrics in order to more accurately reflect the relative severity posed by avulnerability to a user’s environment at a specific point in time. Scoring theTemporal and Environmental metrics is not required, but is recommended for moreprecise scores.

Generally, the Base and Temporal metrics are specified by vulnerability bulletinanalysts, security product vendors, or application vendors because theytypically possess the most accurate information about the characteristics of avulnerability. The Environmental metrics are specified by end-user organizationsbecause they are best able to assess the potential impact of a vulnerabilitywithin their own computing environment.

Scoring CVSS metrics also produces a vector string, a textual representation ofthe metric values used to score the vulnerability. This vector string is aspecifically formatted text string that contains each value assigned to eachmetric, and should always be displayed with the vulnerability score.

The scoring equations and vector string are explained further below.

Note that all metrics should be scored under the assumption that the attackerhas already located and identified the vulnerability. That is, the analyst neednot consider the means by which the vulnerability was identified. In addition,it is likely that many different types of individuals will be scoringvulnerabilities (e.g., software vendors, vulnerability bulletin analysts,security product vendors), however, note that vulnerability scoring is intendedto be agnostic to the individual and their organization.

2.1. Exploitability Metrics

As previously mentioned, the Exploitability metrics reflect the characteristicsof the thing that is vulnerable, which we refer to formally as the vulnerablecomponent. Therefore, each of the Exploitability metrics listed below should bescored relative to the vulnerable component, and reflect the properties of thevulnerability that lead to a successful attack.

When scoring Base metrics, it should be assumed that the attacker has advancedknowledge of the weaknesses of the target system, including generalconfiguration and default defense mechanisms (e.g., built-in firewalls, ratelimits, traffic policing). For example, exploiting a vulnerability that resultsin repeatable, deterministic success should still be considered a Low value forAttack Complexity, 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 Score, i.e., if a specific configuration is required for an attack tosucceed, the vulnerable component should be scored assuming it is in thatconfiguration.

2.1.1. Attack Vector (AV)

This metric reflects the context by which vulnerability exploitation ispossible. This metric value (and consequently the Base Score) will be larger themore remote (logically, and physically) an attacker can be in order to exploitthe vulnerable component. 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 greater BaseScore. The list of possible values is presented in Table 1.

Table 1: Attack Vector

Scoring Guidance: When deciding between Network and Adjacent, if an attack canbe launched over a wide area network or from outside the logically adjacentadministrative network domain, use Network. Network should be used even if theattacker is required to be on the same intranet to exploit the vulnerable system(e.g., the attacker can only exploit the vulnerability from inside a corporatenetwork).

2.1.2. Attack Complexity (AC)

This metric describes the conditions beyond the attacker’s control that mustexist in order to exploit the vulnerability. As described below, such conditionsmay require the collection of more information about the target, orcomputational exceptions. Importantly, the assessment of this metric excludesany requirements for user interaction in order to exploit the vulnerability(such conditions are captured in the User Interaction metric). If a specificconfiguration is required for an attack to succeed, the Base metrics should bescored assuming the vulnerable component is in that configuration. The BaseScore is greatest for the least complex attacks. The list of possible values ispresented in Table 2.

Table 2: Attack Complexity

As described in Section 2.1, detailed knowledge of the vulnerable component isoutside the scope of Attack Complexity. Refer to that section for additionalguidance when scoring Attack Complexity when target-specific attack mitigationis present.

2.1.3. Privileges Required (PR)

This metric describes the level of privileges an attacker must possess beforesuccessfully exploiting the vulnerability. The Base Score is greatest if noprivileges are required. The list of possible values is presented in Table 3.

Table 3: Privileges Required

Scoring Guidance: Privileges Required is usually None for hard-coded credentialvulnerabilities or vulnerabilities requiring social engineering (e.g., reflectedcross-site scripting, cross-site request forgery, or file parsing vulnerabilityin a PDF reader).

2.1.4. User Interaction (UI)

This metric captures the requirement for a human user, other than the attacker,to participate in the successful compromise of the vulnerable component. Thismetric determines whether the vulnerability can be exploited solely at the willof the attacker, or whether a separate user (or user-initiated process) mustparticipate in some manner. The Base Score is greatest when no user interactionis required. The list of possible values is presented in Table 4.

Table 4: User Interaction

2.2. Scope (S)

The Scope metric captures whether a vulnerability in one vulnerable componentimpacts resources in components beyond its security scope.

Formally, a security authority is a mechanism (e.g., an application, anoperating system, firmware, a sandbox environment) that defines and enforcesaccess control in terms of how certain subjects/actors (e.g., human users,processes) can access certain restricted objects/resources (e.g., files, CPU,memory) in a controlled manner. All the subjects and objects under thejurisdiction of a single security authority are considered to be under onesecurity scope. If a vulnerability in a vulnerable component can affect acomponent which is in a different security scope than the vulnerablecomponent, a Scope change occurs. Intuitively, whenever the impact of avulnerability breaches a security/trust boundary and impacts components outsidethe security scope in which vulnerable component resides, a Scope change occurs.

The security scope of a component encompasses other components that providefunctionality solely to that component, even if these other components havetheir own security authority. For example, a database used solely by oneapplication is considered part of that application’s security scope even if thedatabase has its own security authority, e.g., a mechanism controlling access todatabase records based on database users and associated database privileges.

The Base Score is greatest when a scope change occurs. The list of possiblevalues is presented in Table 5.

Table 5: Scope

2.3. Impact Metrics

The Impact metrics capture the effects of a successfully exploited vulnerabilityon the component that suffers the worst outcome that is most directly andpredictably associated with the attack. Analysts should constrain impacts to areasonable, final outcome which they are confident an attacker is able toachieve.

Only the increase in access, privileges gained, or other negative outcome as aresult of successful exploitation should be considered when scoring the Impactmetrics of a vulnerability. For example, consider a vulnerability that requiresread-only permissions prior to being able to exploit the vulnerability. Aftersuccessful exploitation, the attacker maintains the same level of read access,and gains write access. In this case, only the Integrity impact metric should bescored, and the Confidentiality and Availability Impact metrics should be set asNone.

Note that when scoring a delta change in impact, the final impact should beused. For example, if an attacker starts with partial access to restrictedinformation (Confidentiality Low) and successful exploitation of thevulnerability results in complete loss in confidentiality (ConfidentialityHigh), then the resultant CVSS Base Score should reference the “end game” Impactmetric value (Confidentiality High).

If a scope change has not occurred, the Impact metrics should reflect theConfidentiality, Integrity, and Availability impacts to the vulnerablecomponent. However, if a scope change has occurred, then the Impact metricsshould reflect the Confidentiality, Integrity, and Availability impacts toeither the vulnerable component, or the impacted component, whichever suffersthe most severe outcome.

2.3.1. Confidentiality (C)

This metric measures the impact to the confidentiality of the informationresources managed by a software component due to a successfully exploitedvulnerability. Confidentiality refers to limiting information access anddisclosure to only authorized users, as well as preventing access by, ordisclosure to, unauthorized ones. The Base Score is greatest when the loss tothe impacted component is highest. The list of possible values is presented inTable 6.

Table 6: Confidentiality

2.3.2. Integrity (I)

This metric measures the impact to integrity of a successfully exploitedvulnerability. Integrity refers to the trustworthiness and veracity ofinformation. The Base Score is greatest when the consequence to the impactedcomponent is highest. The list of possible values is presented in Table 7.

Table 7: Integrity

2.3.3. Availability (A)

This metric measures the impact to the availability of the impacted componentresulting from a successfully exploited vulnerability. While the Confidentialityand Integrity impact metrics apply to the loss of confidentiality or integrityof data (e.g., information, files) used by the impacted component, this metricrefers to the loss of availability of the impacted component itself, such as anetworked service (e.g., web, database, email). Since availability refers to theaccessibility of information resources, attacks that consume network bandwidth,processor cycles, or disk space all impact the availability of an impactedcomponent. The Base Score is greatest when the consequence to the impactedcomponent is highest. The list of possible values is presented in Table 8.

Table 8: Availability

The Temporal metrics measure the current state of exploit techniques or codeavailability, the existence of any patches or workarounds, or the confidence inthe description of a vulnerability.

3.1. Exploit Code Maturity (E)

This metric measures the likelihood of the vulnerability being attacked, and istypically based on the current state of exploit techniques, exploit codeavailability, or active, “in-the-wild” exploitation. Public availability ofeasy-to-use exploit code increases the number of potential attackers byincluding those who are unskilled, thereby increasing the severity of thevulnerability. Initially, real-world exploitation may only be theoretical.Publication of proof-of-concept code, functional exploit code, or sufficienttechnical details necessary to exploit the vulnerability may follow.Furthermore, the exploit code available may progress from a proof-of-conceptdemonstration to exploit code that is successful in exploiting the vulnerabilityconsistently. In severe cases, it may be delivered as the payload of anetwork-based worm or virus or other automated attack tools.

The list of possible values is presented in Table 9. The more easily avulnerability can be exploited, the higher the vulnerability score.

Table 9 : Exploit Code Maturity

The Remediation Level of a vulnerability is an important factor forprioritization. The typical vulnerability is unpatched when initially published.Workarounds or hotfixes may offer interim remediation until an official patch orupgrade is issued. Each of these respective stages adjusts the Temporal Scoredownwards, reflecting the decreasing urgency as remediation becomes final. Thelist of possible values is presented in Table 10. The less official andpermanent a fix, the higher the vulnerability score.

Table 10: Remediation Level

3.3. Report Confidence (RC)

This metric measures the degree of confidence in the existence of thevulnerability and the credibility of the known technical details. Sometimes onlythe existence of vulnerabilities is publicized, but without specific details.For example, an impact may be recognized as undesirable, but the root cause maynot be known. The vulnerability may later be corroborated by research whichsuggests where the vulnerability may lie, though the research may not becertain. Finally, a vulnerability may be confirmed through acknowledgment by theauthor or vendor of the affected technology. The urgency of a vulnerability ishigher when a vulnerability is known to exist with certainty. This metric alsosuggests the level of technical knowledge available to would-be attackers. Thelist of possible values is presented in Table 11. The more a vulnerability isvalidated by the vendor or other reputable sources, the higher the score.

Table 11: Report Confidence

These metrics enable the analyst to customize the CVSS score depending on theimportance of the affected IT asset to a user’s organization, measured in termsof complementary/alternative security controls in place, Confidentiality,Integrity, and Availability. The metrics are the modified equivalent of Basemetrics and are assigned values based on the component placement withinorganizational infrastructure.

4.1. Security Requirements (CR, IR, AR)

These metrics enable the analyst to customize the CVSS score depending on theimportance of the affected IT asset to a user’s organization, measured in termsof Confidentiality, Integrity, and Availability. That is, if an IT assetsupports a business function for which Availability is most important, theanalyst can assign a greater value to Availability relative to Confidentialityand Integrity. Each Security Requirement has three possible values: Low, Medium,or High.

The full effect on the environmental score is determined by the correspondingModified Base Impact metrics. That is, these metrics modify the environmentalscore by reweighting the Modified Confidentiality, Integrity, and Availabilityimpact metrics. For example, the Modified Confidentiality impact (MC) metric hasincreased weight if the Confidentiality Requirement (CR) is High. Likewise, theModified Confidentiality impact metric has decreased weight if theConfidentiality Requirement is Low. The Modified Confidentiality impact metricweighting is neutral if the Confidentiality Requirement is Medium. This sameprocess is applied to the Integrity and Availability requirements.

Note that the Confidentiality Requirement will not affect the Environmentalscore if the (Modified Base) confidentiality impact is set to None. Also,increasing the Confidentiality Requirement from Medium to High will not changethe Environmental score when the (Modified Base) impact metrics are set to High.This is because the Modified Impact Sub-Score (part of the Modified Base Scorethat calculates impact) is already at a maximum value of 10.

The list of possible values is presented in Table 12. For brevity, the sametable is used for all three metrics. The greater the Security Requirement, thehigher the score (recall that Medium is considered the default).

Table 12: Security Requirements

4.2. Modified Base Metrics

These metrics enable the analyst to override individual Base metrics based onspecific characteristics of a user’s environment. Characteristics that affectExploitability, Scope, or Impact can be reflected via an appropriately modifiedEnvironmental Score.

The full effect on the Environmental score is determined by the correspondingBase metrics. That is, these metrics modify the Environmental Score byoverriding Base metric values, prior to applying the Environmental SecurityRequirements. For example, the default configuration for a vulnerable componentmay be to run a listening service with administrator privileges, for which acompromise might grant an attacker Confidentiality, Integrity, and Availabilityimpacts that are all High. Yet, in the analyst’s environment, that same Internetservice might be running with reduced privileges; in that case, the ModifiedConfidentiality, Modified Integrity, and Modified Availability might each be setto Low.

For brevity, only the names of the Modified Base metrics are mentioned. EachModified Environmental metric has the same values as its corresponding Basemetric, plus a value of Not Defined. Not Defined is the default and uses themetric value of the associated Base metric.

The intent of this metric is to define the mitigations in place for a givenenvironment. It is acceptable to use the modified metrics to representsituations that increase the Base Score. For example, the default configurationof a component may require high privileges to access a particular function, butin the analyst’s environment there may be no privileges required. The analystcan set Privileges Required to High and Modified Privileges Required to None toreflect this more serious condition in their particular environment.

The list of possible values is presented in Table 13.

Table 13: Modified Base Metrics

For some purposes it is useful to have a textual representation of the numericBase, Temporal and Environmental scores. All scores can be mapped to thequalitative ratings defined in Table 14.³

Table 14: Qualitative severity rating scale

As an example, a CVSS Base Score of 4.0 has an associated severity rating ofMedium. The use of these qualitative severity ratings is optional, and there isno requirement to include them when publishing CVSS scores. They are intended tohelp organizations properly assess and prioritize their vulnerability managementprocesses.

The CVSS v3.1 vector string is a text representation of a set of CVSS metrics.It is commonly used to record or transfer CVSS metric information in a conciseform.

The CVSS v3.1 vector string begins with the label “CVSS:” and a numericrepresentation of the current version, “3.1”. Metric information follows in theform of a set of metrics, each preceded by a forward slash, “/”, acting as adelimiter. Each metric is a metric name in abbreviated form, a colon, “:”, andits associated metric value in abbreviated form. The abbreviated forms aredefined earlier in this specification (in parentheses after each metric name andmetric value), and are summarized in the table below.

A vector string should contain metrics in the order shown in Table 15, thoughother orderings are valid. All Base metrics must be included in a vector string.Temporal and Environmental metrics are optional, and omitted metrics areconsidered to have the value of Not Defined (X). Metrics with a value of NotDefined can be explicitly included in a vector string if desired. Programsreading CVSS v3.1 vector strings must accept metrics in any order and treatunspecified Temporal and Environmental as Not Defined. A vector string must notinclude the same metric more than once.

Table 15: Base, Temporal and Environmental Vectors

For example, a vulnerability with Base metric values of “Attack Vector: Network,Attack Complexity: Low, Privileges Required: High, User Interaction: None,Scope: Unchanged, Confidentiality: Low, Integrity: Low, Availability: None” andno specified Temporal or Environmental metrics would produce the followingvector:

CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N

The same example with the addition of “Exploitability: Functional, RemediationLevel: Not Defined” and with the metrics in a non-preferred ordering wouldproduce the following vector:

CVSS:3.1/S:U/AV:N/AC:L/PR:H/UI:N/C:L/I:L/A:N/E:F/RL:X

The CVSS v3.1 equations are defined in the sub-sections below. They rely onhelper functions defined as follows:

• Minimum returns the smaller of its two arguments.
• Roundup returns the smallest number, specified to 1 decimal place,that is equal to or higher than its input. For example, Roundup (4.02)returns 4.1; and Roundup (4.00) returns 4.0. To ensureconsistent results across programming languages and hardware, see Appendix Afor advice to Implementers on avoiding small inaccuracies introduced in somefloating point implementations.

Substitute Individual metrics used in equations with the associated constantlisted in Section 7.4.

7.1. Base Metrics Equations

The Base Score formula depends on sub-formulas for Impact Sub-Score (ISS),Impact, and Exploitability, all of which are defined below:

7.2. Temporal Metrics Equations

7.3. Environmental Metrics Equations

The Environmental Score formula depends on sub-formulas for Modified ImpactSub-Score (MISS), ModifiedImpact, and ModifiedExploitability, all of which aredefined below:

Note that the exponent at the end of the ModifiedImpact sub-formula is 13,which differs from CVSS v3.0. See the User Guide for more details of thischange.

7.4. Metric Values

Each metric value has an associated constant which is used in the formulas, asdefined in Table 16.

Table 16: Metric values

7.5. A Word on CVSS v3.1 Equations and Scoring

The CVSS v3.1 formula provides a mathematical approximation of all possiblemetric combinations ranked in order of severity (a vulnerability lookup table).To produce the CVSS v3.1 formula, the CVSS Special Interest Group (SIG) framedthe lookup table by assigning metric values to real vulnerabilities, and aseverity group (low, medium, high, critical). Having defined the acceptablenumeric ranges for each severity level, the SIG then collaborated with Deloitte& Touche LLP to adjust formula parameters in order to align the metriccombinations to the SIG's proposed severity ratings.

Given that there are a limited number of numeric outcomes (101 outcomes, rangingfrom 0.0 to 10.0), multiple scoring combinations may produce the same numericscore. In addition, some numeric scores may be omitted because the weights andcalculations are derived from the severity ranking of metric combinations.Further, in some cases, metric combinations may deviate from the desiredseverity threshold. This is unavoidable and a simple correction is not readilyavailable because adjustments made to one metric value or equation parameter inorder to fix a deviation, cause other, potentially more severe deviations.

By consensus, and as was done with CVSS v2.0, the acceptable deviation was avalue of 0.5. That is, all the metric value combinations used to derive theweights and calculation will produce a numeric score within its assignedseverity level, or within 0.5 of that assigned level. For example, a combinationexpected to be rated as a “high” may have a numeric score between 6.6 and 9.3.Finally, CVSS v3.1 retains the range from 0.0 to 10.0 for backwardcompatibility.

Simple implementations of the Roundup function defined in Section 7 are likelyto lead to different results across programming languages and hardwareplatforms. This is due to small inaccuracies that occur when using floatingpoint arithmetic. For example, although the intuitive result of 0.1+0.2 is0.3, JavaScript implementations on many systems return0.30000000000000004. A simple implementation of Roundup would round this upto to 0.4, which is counter-intuitive.

Implementers of CVSS formulas must take steps to avoid these types of problems.Different techniques may be required for different languages and platforms, andsome may offer standard functionality that minimizes or fully avoids suchproblems.

A suggested approach is for the Roundup function to first multiply its input by100,000 and convert it to the nearest integer. The rounding up should then beperformed using only integer arithmetic, which is not subject to floating pointinaccuracies. An example of pseudocode for such an implementation is:

1. function Roundup (input):
2. int_input = round_to_nearest_integer (input * 100000)
3. if (int_input % 10000) == 0:
4. return int_input / 100000.0
5. else:
6. return (floor(int_input / 10000) + 1) / 10.0

The floor function on line 6 represents integer division, i.e., the largestinteger value less than or equal to its input. Many programming languagesinclude a floor function as standard.

Line 3 checks if the least significant four digits of the integer are allzeroes, e.g., an input of 1.200003 would be converted by line 2 into 120,003,making the result of the modulo operation 0 and therefore the if statementcondition is true. If true, no additional rounding is required. If false,the integer is incremented by 0.1 before being returned, though line 6 performsthis on numbers ten times bigger than the result will be in order to use integerarithmetic.

FIRST sincerely recognizes the contributions of the following CVSS SpecialInterest Group (SIG) members, listed in alphabetical order:

• Adam Maris (Red Hat)
• Arkadeep Kundu (Dell)
• Arnold Yoon (Dell)
• Art Manion (CERT/CC)
• Bruce Lowenthal (Oracle)
• Bruce Monroe (Intel)
• Charles Wergin (NIST)
• Christopher Turner (NIST)
• Cosby Clark (IBM)
• Dale Rich (Depository Trust & Clearing Corporation)
• Damir 'Gaus' Rajnovic (Panasonic)
• Daniel Sommerfeld (Microsoft)<- Darius Wiles (Oracle)
• Dave Dugal (Juniper)
• Deana Shick (CERT/CC)
• Fabio Olive Leite (Red Hat)
• James Kohli ️(GE Healthcare)
• Jeffrey Heller (Sandia National Laboratories)
• John Stuppi (Cisco)
• Jorge Orchilles (Citi)
• Karen Scarfone (Scarfone Cybersecurity)
• Luca Allodi (Eindhoven University of Technology)
• Masato Terada (Information-Technology Promotion Agency, Japan)
• Max Heitman (Citi)
• Melinda Rosario (SecureWorks)
• Nazira Carlage (Dell)
• Rani Kehat (Radiflow)
• Renchie Abraham (SAP)
• Sasha Romanosky (Carnegie Mellon University)
• Scott Moore (IBM)
• Troy Fridley (Cisco)
• Vijayamurugan Pushpanathan (Schneider Electric)
• Wagner Santos (UFCG)

FIRST would also like to thank Abigail Palacios and Vivian Smith from ConradInc. for their tireless work facilitating the CVSS SIG meetings.

• CVSS main page - https://www.first.org/cvss/
  The main web page for all CVSS resources, including the most recent version ofthe CVSS standard.

• Specification Document - https://www.first.org/cvss/specification-document
  The latest revision of this document, defining the metrics, formulas,qualitative rating scale and vector string.

• User Guide - https://www.first.org/cvss/user-guide
  A companion to the Specification, the User Guide includes further discussion ofthe CVSS standard including particular use cases, guidelines on scoring, scoringrubrics, and a glossary of the terms used in the Specification and User Guidedocuments.

• Examples Document - https://www.first.org/cvss/examples
  Includes scores of public vulnerabilities and explanations of why particularmetric values were chosen.

• Calculator - https://www.first.org/cvss/calculator/3.1
  A reference implementation of the CVSS standard that can be used for generatingscores. The underlying code is documented and can be used as part of otherimplementations.

• JSON and XML Schemas - https://www.first.org/cvss/data-representations
  Data representations for CVSS metrics, scores and vector strings in JSON Schemaand XML Schema Definition (XSD) representations. These can be used to store andtransfer CVSS information in defined JSON and XML formats.