Common Vulnerability Scoring System v4.0: Frequently Asked Questions (FAQ)
Also availablein PDF format (519KiB).
Document Version: 1.6
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.
This document provides answers to frequently asked questions regarding CVSSversion 4.0.
The most current CVSS resources can be found athttps://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 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 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.
Introduction
During the development of version 4.0 of the Common Vulnerability Scoring System(CVSS), many excellent questions and comments were provided during the publiccomment period.
As a supplement to the CVSS version 4.0 Specification Document, User Guide, andExamples Document, this set of frequently asked questions (FAQs) and answers hasbeen collected in order to aid in the adoption and understanding of the newstandard.
Resources & Links
Below are useful references to additional CVSS v4.0 documents.
Frequently Asked Questions
Is there a prescribed way to use CVSS Base and Environmental metrics to score a vulnerability along a long supply chain?
Answer - No.
What’s the difference between Attack Complexity (AC) and Attack Requirements (AT)?
The concept of Attack Complexity (AC) in CVSS v3.1 has now been expandedinto two base metrics: Attack Complexity (AC) and ATtack Requirements (AT).The differences between Attack Complexity and Attack Requirements can bestbe understood as:
Attack Complexity: BUILT-IN CHALLENGES: Actions must be taken by theattacker to actively evade or circumvent built-in security-enhancingconditions. Examples include: ASLR and DEP.
Alternatively, the attacker must gather some target-specific secret beforethe attack can be successful. A secret is any piece of information thatcannot be obtained through any amount of reconnaissance. To obtain thesecret the attacker must perform additional attacks or break otherwisesecure measures (e.g. knowledge of a secret key may be needed to break acrypto channel).
Note: When performing a site-specific assessment, presence of a built-infirewall filter as a compensating control can be represented via theModified Attack Complexity (MAC) Environmental metric.
Attack Requirements: EXTERNAL CHALLENGES: Deployment and executionconditions or variables of the vulnerable system must be overcome. Examplesinclude: race conditions or on-path network injection (also known as Machinein the Middle or MITM).
Note: When performing a site-specific assessment, presence of anexternal firewall filter as a compensating control can be represented viathe Modified Attack Requirements (MAT) Environmental metric.
Why did you use “AT” for Attack Requirements, instead of “AR”?
AR was already being used for Availability Requirements. The Specificationwill not allow two metrics to have the same abbreviation.
What are the boundaries between a Vulnerable System and Subsequent System?
For the purpose of determining Vulnerable System versus Subsequent Systemimpacts, keep in mind these factors:
When thinking about the Vulnerable System, consider the scope of where thevulnerability exists and from which it will be exploited; the factors forAV, AC, AT, PR, and UI will be determined based on this. If, for example, avulnerability exists in a specific service or module which is part of alarger unit, and is not able to stand on its own, then the scope of theVulnerable System would almost certainly be the containing unit.
A concrete example: an application delivered by a vendor contains multipleservices, one of which contains a vulnerability; if the specific service isnot independent of — or to put another way, is integral to — the largercollection of services, the vulnerability would be reported against theapplication, and the Vulnerable System would likewise be the application.
Subsequent Systems encompass anything that is not the Vulnerable System andis impacted in some way by the vulnerability in the Vulnerable System.
Using the application/service example above, if the service can be separatedfrom the rest of the components (e.g., the vendor may supply both, but oneis not integral to the other), the scope of the vulnerability would bereported as within the service consumed by the application. In this example,the Vulnerable System would be the service rather than the application. Ifthe application’s security is impacted from the vulnerability in theservice, the application would be among the Subsequent Systems affected bythe vulnerability.
Be sure to check out the Examples Document for variations of how VulnerableSystem and Subsequent Systems are identified and assessed.
Supplemental Metrics do not affect the final score. What is the recommended way to consume and respond to Supplemental Metric assessment?
Consumers are encouraged to consider more than just the simple numericalscore and understand the full context and nuance of a vulnerability’scapabilities and impact. Also, there is important and valuable informationthat can be provided to the consumer that does not impact the severity ofthe vulnerability. For example, a denial of service (DoS) vulnerability thatimmediately recovers (R:A) has the same numeric score as a DoS vulnerabilitythat leaves the system unavailable until an administrator restarts thesystem (R:U). However, the length of service impact may differ greatly andcan be considered by the consumer when planning remediation resources.
Another example is a Border Gateway Protocol (BGP) networking vulnerabilitythat forwards the malicious update and then crashes (AU:Y), causing acascade outage vs. the same vulnerability that crashes without forwarding(AU:N). The technical severity is the same, but the scope of service impactis far greater for an automatable vulnerability.
Think of Supplemental Metrics as an extended vocabulary for conveyinginformation about the extrinsic characteristics, or outward impact, of avulnerability beyond just the technical severity. If we consider the CVSSv4.0 vector as a "vocabulary" of vulnerability assessment, the moreinformation a supplier can provide the consumer, the more decisions can bemade with complete situational awareness. Much like the expansion of theImpact Metrics, allowing suppliers to provide full disclosure on the impactof a vulnerability, Supplemental Metrics provide additional extrinsiccharacteristics of the vulnerability (e.g., wormable, difficulty ofmitigation, objective vendor urgency, etc.) that can be used when decidingwhich High or Critical severity vulnerability to patch first.
It’s also important to distinguish the difference between the assessment(assignment) of the Supplemental Metrics by thescoring provider, versusthe assessment (response plan) of theconsumer. Product suppliers assessthe additional characteristics of the vulnerability and assign applicableSupplemental Metric values. Product consumers review the providedSupplemental Metric values and assess whether any modifications of theirvulnerability response (e.g., mitigation priority) is warranted.
What is the guidance on what action to take for the various values of the Safety (S) Supplemental Metric: Negligible (N) and Present (P)?
When a Safety metric value of Negligible has been assessed, it means thatwhomever did the assessment believes that there should be no concerns aboutpotential operational safety impact unless the vulnerable device has anobvious potential impact to human safety based on how it is being used inthe consumer’s environment. A Safety metric value of Present, it means thatwhomever did the assessment believes that there is at least some potentialfor an operational safety impact in most, if not all instances of itsdeployment. The context of the system and the consumer’s concerns withrespect to the use of the system may suggest very different guidance fordifferent situations.
Additionally, what is meant by “consequences of the vulnerability meet definition of IEC 61508 consequence categories of ‘marginal,’ ‘critical,’ or ‘catastrophic.’”?
The consequences of the vulnerability refer to potential Safety impacts. IEC61508 provides some handy references for understanding potential safetycategories. A snapshot of a table from Wikipedia1 on this subject isshown below:
Consequence Categories
| Category | Definition |
|---|
| Catastrophic | Multiple loss of life |
| Critical | Loss of a single life |
| Marginal | Major injuries to one or more persons |
| Negligible | Minor injuries at worst |
In the above table, you can see the same consequence categories that havebeen introduced in the description of Safety metrics. This version of CVSSis focusing on considering a safety impact that either doesn’t (Negligible)or does (anything more severe than Negligible) create a potential safetyconcern.
What is the guidance on what action to take for the various values of the Automatable (AU) Supplemental Metric: No (N) and Yes (Y)?
If exploitation of a vulnerability is automatable by an attacker, you shouldconsider a higher priority for mitigating or fixing the vulnerability.
An answer of Yes to Automatable is aligned with the vulnerability beingwormable,2 that is, the vulnerability can be used by a self-replicatingattack that can spread at machine speed. Because this reduces an defender’savailable time between receiving reports of active exploitation and attacksagainst their own systems, consider mitigating or remediating anyAutomatable vulnerabilities as soon as there is a public proof of conceptexploit.
What is the guidance on what action to take for the various values of the Recovery (R) Supplemental Metric: Automatic (A), User (U), and Irrecoverable (I)?
The spirit and intent of adding Recovery a Supplemental metric was forconsumers to consider the post attack scenario and assess the actual impact.
Recovery metric describes the method of recovery of a component or serviceonce an attack has been carried out.
Automatic Recovery (A) : This metric describes that the system orcomponent can recover by itself within no time. Eg: A line card in anetworking device could reboot and restart on its own , without causing anyservice intervention. This is the same as a daemon restarting upon anattack, automatically. In these case, the downtime is almost negligible.
User Recovery (U) : This metric describes that the system or componentcannot recover on its own, but requires a human intervention. Eg: A manualrestart due to persistent memory leak leading to a Denial of Service on thesystem.
Irrecoverable (I) : This metric describes that the system or componentis beyond repair and cannot recover on its own. Eg: CPU releases smoke dueto colling fan malfunctioning or any hardware failure that needs areplacement.
Note that User (U) represents actions possible by an operator, consumer, orend customer. The recovery of a Component/System includes servicerestoration in terms of availability and performance. Auto recovery islimited in scope to the component itself.
What is the guidance on what action to take for the various values of the Value Density (V) Supplemental Metric: Diffuse (D) and Concentrated (C)?
Value Density is primarily a property of the system which contains thevulnerability, rather than the vulnerability itself. Therefore, ValueDensity is less likely to be useful for a software vendor or maintainer whois prioritizing work within one software product. Anyone that isprioritizing vulnerability actions among work that includes multipleproducts (such as a manager at a large supplier deciding among projects, acoordinator, or any software consumer or system owner) should considermitigations and remediations to systems with Concentrated Value Density as ahigher priority than those with Diffuse Value Density. Concentrated ValueDensity systems are a higher priority to mitigate or remediate because theyare a higher priority for adversaries to attack.
What is the guidance on what action to take for the various values of the Vulnerability Response Effort (RE) Supplemental Metric: Low (L), Moderate (M), and High (H)?
The intent of the Vulnerability Response Effort (RE) Supplemental Metric wasfor consumers to use that information to plan out their mitigationdeployments and the resources that would be needed.
Low (L) – non intrusive change simple to deploy. Low impact to systems likeupdating documentation.
Medium (M) – Software drivers and other items that can be mitigated quickly.
High (H) – More complicated typically low level software or firmware whereplatform reboots would be required (Especially in a Data Centerenvironment.)
What is the guidance on what action to take for the various values of the Provider Urgency (U) Supplemental Metric: Clear, Green, Amber, and Red?
It may be helpful to think of the Provider Urgency as the “low order bits”of the severity rating. For example, given two unauthenticated network-baseddenial of service vulnerabilities (CVSS-B 8.7), the vulnerability identifiedby the supplier (eg. vendor) with a higher Provider Urgency may be worthconsidering being remediated first.
Cases where a supplier may set a higher than neutral Provider Urgencyinclude vulnerabilities that don’t qualitatively reflect the criticality ofthe issue, given its CVSS-B score. Conversely, cases where a provider mayset a lower Provider Urgency include vulnerabilities that result in asubjectively higher CVSS-B score than the product provider would haveassessed, for example, in their public security advisory.
Note that suppliers may assess a Provider Urgency thataligns with theQualitative Severity Rating Scale3, neither raising nor lowering the baseremediation priority.
While any provider along the product supply chain may provide a SupplementalUrgency rating:
Library Maintainer → OS/Distro Maintainer → Provider 1 …Provider n(PPP) → Consumer
the Penultimate Product Provider (PPP) is best positioned to provide themost direct assessment of Urgency.
Additionally, why were TLP colors chosen, rather than simply Low, Moderate, and High?
The intent of the supplemental assessment Provider Urgency was to provideadditional insight into the vulnerability's impact. Care was taken tolimit this metric to specifically augmenting the assessment, rather thanoverriding the CVSS-B score. Had linear values such as Low, Moderate, andHigh been selected for Provider Urgency, consumers may have misinterpretedit as an overruled assessment of the severity, invalidating the methodicallycalculated CVSS-B score.Answer
How did CVSS v4.0 address the issue of scores being too clustered toward High and Critical severity ratings?
The perception that CVSS v3.1 scores were clustered toward the Critical andHigh ratings was not a problem the CVSS SIG was intending to solve in v4.0.It is natural for suppliers to focus their efforts to assess, announce, andprovide fixes for the most severe vulnerabilities they identify in theirproducts. As a result, more vulnerabilities are rated higher on the severityscale than others.
It is the responsibility of the consumer to apply Threat and Environmentaldata into the assessment of the vulnerabilities (preferably usingautomation) to reduce the scores of the vulnerabilities that are not asimportant as others. For example, vulnerabilities that are not beingexploited in the wild nor have proof-of-concept code publicly available willrealize a significant reduction in the CVSS-BTE score. Exploitedvulnerabilities will maintain their higher scores allowing the consumer tofocus on what is important.
How does the value of Attack Complexity (AC) or Attack Requirements (AT) vary with the introduction of compensating controls (e.g., WAF, CSP, etc.)?
This is related to the application of Environmental Metrics into thevulnerability assessment. Please refer to “How does a consumer applyEnvironmental data into a CVSS Assessment?” below for more details.
Which value of User Interaction (UI), Passive (P) or Active (A), should be used for Reflected Cross-Site Scripting (XSS) or Stored Cross-Site Scripting vulnerabilities?
Reflected cross-site scripting requires that an individual click a specificlink to trigger the exploit. That individual has the choice or opportunityto review the link prior to interacting with it. A conscious decision ismade to interact with the payload, so this would be considered Active.
Stored cross-site scripting does not require a specially crafted link totrigger the exploit. An individual browsing a website could inadvertentlytrigger the exploit through standard browsing behaviors and would have noawareness or ability to avoid the payload prior to exploitation. Becausethere isn’t a conscious decision to interact with the payload, this would beconsidered Passive.
Is clicking a link Passive (P) or Active (A) User Interaction?
Prior to clicking a link, an individual has the choice or opportunity toreview the link. Because the individual is making a conscious decision tointeract with the payload that is delivered via a link, this would beconsidered Active.
Which system is considered the Vulnerable System or the Subsequent System when assessing Reflected or Stored Cross-Site Scripting (XSS) vulnerabilities?
In a cross-site scripting vulnerability, the web application that containsthe injection point is the Vulnerable System. A user’s browser is theSubsequent System.
Which system is considered the Vulnerable System or the Subsequent System when assessing SQL Injection vulnerabilities?
Different scenarios may exist depending on the configuration of theapplications in use. Our example CVE-2023-30545 is simple, where the webapplication that contains the injection point, the SQL application, and thedirect impact of exploitation are all contained on a single system withoutsubsequent system impact.
Other common scenarios include distributed system configurations in which aSQL database application that contains a vulnerability may be the VulnerableSystem, and other business applications that rely on data within thatdatabase may be impacted by exploitation of the vulnerability, and would beassessed as a Subsequent System.
“It is the responsibility of the consumer to populate the Threat Metric Exploit Maturity (E) based on information regarding the availability of exploitation code/processes and the state of exploitation techniques.”
Why is this the responsibility of the consumer and not the provider (vendor)?
This is a common question that is not unique to CVSS v4.0 but is applicableto all past versions.
If this responsibility were to be placed with the supplier/vendor, it wouldrequire ALL suppliers/vendors to have an accurate and real-timeunderstanding of the Exploit Maturity for every vulnerability thatorganization has ever announced – ever. Obviously, this is not realistic andnot reliable. However, this is exactly what threat intelligence sources andorganizations do best. There are many free and subscription-based threatintelligence feeds available to the consumer that will allow them to applythat data to the maximum number of detected vulnerabilities in theirenvironment.
Why does the application of Threat data only reduce the resulting CVSS Score?
This is a common question that is not unique to CVSS v4.0 but is applicableto all past versions. At first glance, this concept appears to becounter-intuitive. But there are several reasons for it that promotematurity in a Vulnerability Management (VM) program.
For a moment, consider the most dangerous vulnerabilities. If they had abase score of “10”, there’s no room to escalate the severity with threatintelligence or environmental criticality data. On the other hand, if theymaxed out with a lower score (like “8” to leave room for escalation based onthreat), there are even more negative side-effects starting with the factthat there would be no such thing as a Critical vulnerability without theapplication of threat.
When vendors score their vulnerabilities for publication, they are assumingthe “reasonable worst-case scenario” as per the specification. This meanswhile performing the assessments on newly announced vulnerabilities,providers must assume that all vulnerabilities will be exploited and fullyweaponized by malicious actors. It is the responsibility of the consumer toapply available threat intelligence and determine where each of theirdetected vulnerabilities falls in the Exploit Maturity scale. For thosevulnerabilities that ARE exploited and weaponized, their scores will remainhigh. For those that are not exploited and don’t have Proof-of-Concept (POC)code publicly available, those scores will fall and become less important.
How does a consumer apply threat intelligence data into a CVSS Assessment?
This is a common question that is not unique to CVSS v4.0 but is applicableto all past versions.
For Threat, the key is collecting and applying threat intelligence data toyour vulnerability scan data using automation.
Reliable threat intelligence sources are much easier to find now than theywere 10 years ago. There are dozens of inexpensive (or free) places to go toget this information in bulk or and even more if you are able to pay for asubscription service. As you would expect, not all threat intel sources areequal – and none are perfect. It is recommended to use MANY differentsources of threat intelligence and combine the results before applying it toyour scan data.
When you have your vulnerability threat intelligence, it should tell youwhere each CVE is on the threat scale. If your threat intelligence sourcesare not using the CVSS Exploit Code Maturity values, you may have totranslate that data to be usable. When you have machine-readable threatintelligence, reconcile that data with the CVEs identified in yourvulnerability scan data.
Also, it is important to remember that intelligence changes all the time.Therefore, threat intelligence data must be re-collected and re-applied toyour scan data frequently (daily updates are recommended). When these jobsare automated, this maintenance becomes much easier.
How does a consumer apply Environmental data into a CVSS Assessment?
This is a common question that is not unique to CVSS v4.0 but is applicableto all past versions.
The Environmental Metric can be divided into 2 groups
“Security Requirements” which includes Confidentiality Requirements (CR),Integrity Requirements (IR), and Availability Requirements (AR) andrepresent the criticality of the vulnerable device.
“Modified Base Metrics” which, as the name would suggest, allows theconsumer to adjust the values for any of the CVSS Base Metrics asappropriate for their environment.
It is important to understand that the Environmental Metrics are allattributes of the VULNERABLE SYSTEM. They have NO relation to thevulnerability itself.
It is highly recommended that consumers of CVSS perform an assessment of thedevices on their network and document the results in a database (such as anAsset Management Database).
Security Requirements: Using the “Security Requirements” section of the UserGuide as a guideline, the assessors will document CR, IR, and AR values inthe database.
Modified Base Metrics: Additionally, other attributes might be gatheredduring this assessment that can be applied to the Modified Base Metrics.This section can be more unclear since the possibilities are nearly endless.Specific configurations and security controls in place in each consumer’senvironment will be different. However, here are some examples of how thiscan be used.
Example 1: If some systems in a consumer’s environment are isolated from theInternet (i.e.: no inbound or outbound connections), a maximum Attack Vector(AV) value of “Adjacent” can be applied to all vulnerabilities identified onthose systems.
Example 2: If a device has obvious potential to impact human safety (such asa bluetooth insulin pump or application that organizes first responders),sufficient impact to Integrity or Availability could result in theapplication of “Safety” as a subsequent impact.
Example 3: A web application is protected by a Web Application Firewall.Attackers attempting to exploit those vulnerabilities will find thoseattempts much more difficult. Therefore, an increase in the AttackComplexity (AC) would be appropriate.
Once the assessment is complete and documented, the consumer shouldreconcile the database with the vulnerability scan data and apply theseattributes to all vulnerabilities found on each system.
Is EPSS or SSVC a replacement for CVSS?
Additional scoring systems have been recently introduced and adopted tohandle complementary aspects of vulnerability assessment and patch priority.These are welcome additions to the vulnerability scoring toolbox, providinginnovative exploit prediction and decision support.
EPSS: Exploit Prediction Scoring System
A data-driven effort for estimating the likelihood (probability) that asoftware vulnerability will be exploited in the wild within 30 days.
Reference:https://first.org/epss
SSVC: Stakeholder-Specific Vulnerability Categorization
A decision tree system for prioritizing actions during vulnerabilitymanagement.
References:https://cisa.gov/ssvc andhttps://github.com/CERTCC/SSVC
None of these scoring systems is a replacement for another, but can be usedin concert to better assess, predict, and make informed decisions onvulnerability response priority.
How should the Attack Requirements metric be used with regards to system configuration?
Attack Requirements should not be used to denote uncommon or uniqueconfiguration requirements that put a system into a vulnerable state.“Execution conditions or variables of the vulnerable system” in thespecification document refer only to challenges faced by an attacker inachieving successful exploitation, and not the possible configuration valuesthat render the system vulnerable. When uncommon or unique configuration isrequired to put the system into a vulnerable state, producers can includethose details in the vulnerability description.
The assessor should assume vulnerable configuration, as documented in CVSSv4.0 Specification Document 2.1 Exploitability Metrics.
Specific configurations should not impact any attribute contributing to theCVSS Base metric assessment , i.e., if a specific configuration is requiredfor an attack to succeed, the vulnerable system should be assessed assumingit is in that configuration.
How is the User Interaction metric used in relation to CSRF vulnerabilities?
The CVSS Specification Document includes a mention of CSRF in the UserInteraction metric Passive value. This exploit scenario would include maliciouscontent embedded into either the vulnerable application itself, or anothertrusted site the targeted user regularly accesses.
However, in practice, attackers exploit many CSRF vulnerabilities throughthe use of malicious links to another site containing embedded maliciouscontent designed to trigger the CSRF vulnerability.
In both cases, an attacker must trick the victim into viewing a website thatcontains malicious content. Depending on the most likely scenario, the analystmay choose between selecting User Interaction Passive or Active.
Why are CVSS v4.0 scores different from version v3.1 scores?
The new metric scoring system in CVSS version 4.0 is a departure from thealgebra formula in CVSS version 3.0 and 3.1. Things might look a lot differentwhen adopting CVSS v4.0. A number of questions have been asked to the CVSS SIGabout these new scores, and this FAQ will help to supply some of the reasoningbehind the new math.
One important note is that while the CVSS numeric score is a useful shorthandfor vulnerability severity, the score itself does not describe the importantcontext that can be conveyed as part of the entire vector string.
Scores for the same vulnerability are different between v3.1 and v4.0
The method for determining the numeric score is new in CVSS v4.0. The numberresults from expert ranking done by the CVSS SIG members. This is unique inrelation to the algebraic formula of weighting metrics in CVSS v3.0 and v3.1.Naturally, some scores will be different between the two versions of the standard.We think it’s an improvement.
You can read more about the ranking methodology in theCVSS User Guide.
Why do some unique CVSS v4.0 metrics result in the same numeric score?
The potential range of unique CVSS metrics is large. There are over fifteenmillion combinations of CVSS vectors that result in a numeric score. To mapthose many combinations of CVSS vectors to the available 101 scores between0.0 and 10.0, those metrics were combined into similar groups called equivalencysets. The grouping means that some similar vector strings, even though distinct,had to be mapped to the same numeric score.
You can read more about equivalency sets in theCVSS User Guide.
Why do some metrics, such as User Interaction or Privileges Required, have less than expected impact on the resulting score?
The grouping of metrics within equivalency sets means that the User Interactionand Privilege Required metrics are grouped with combinations of Attack Vectormetrics. See Table 24 in theCVSS Specification Document.As a result, there was only so much available fidelity for numeric scores and these metrics.
This relates to the limitation of there being many more combinations of metricsthan spaces in the 101 available scores in the 0 to 10 scale.
An effort was made to make scores more distinct, by adding a fuzzing featureto the CVSS v4.0 calculator. However, to avoid disrupting the ranking systemtoo much, the scoring difference was limited to 0.1 when selecting different metrics.
Why do subsequent system metric scores with any combination of non- High SC, SI, or SA metrics result in the same score?
Example: The following metric strings all equate to the same numeric score, a CVSS score of 9.3.
• CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L
• CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:L/SA:L
• CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:L
• CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
This scoring question again relates to the grouping of metrics into equivalencysets to deal with the limited range of scores between 0 and 10. The addition ofthe Safety metric further reduces the potential unique scores for this set ofmetrics. The constraints for subsequent system metrics group each of the Low orNone metrics for Subsequent System Confidentiality, Integrity, and Availabilityinto one level. As a result, any combination of these scores (Low / Low / Lowthrough None / None / None) become equal and the score does not change. See Table 27in theCVSS Specification Documentfor the details on this grouping.
How can I implement a CVSS calculator for my own organization?
A number of community-developed CVSS calculator libraries have been developed tohelp with this purpose. See the end of this FAQ entry for a list of CVSS helper libraries.
This guide can help you with implementing and validating the accuracy of a calculatorfor your own organization. The way to derive numeric scores from vector strings is alittle different with CVSS v4.0. If you want to use one of the libraries put forth bythe community, or develop a CVSS calculator library of your own, you should have away to make sure you get results consistent with the CVSS v4.0 standard.
The CVSS SIG cannot check each calculator for consistent scoring. It is up to themaintainer of each library to verify their own scoring consistency, and for eachcalculator implementer to check their own results.
How can you make sure your calculator is consistent with the official standard?
Calculator Validation Steps
If you are interested in implementing a calculator that will work for yourorganization, consider the following ways to validate that your calculatorreturns results consistent with the standard.
The Full Metric Space
There are roughly fifteen million valid CVSS v4 metric strings. Ideally,your calculator implementation should return the correct value for each, anda negative result for the trillions of other potential but invalid combinations.
Sounds like a tall task? It may be. The CVSS SIG is working on ways to checkthe full metric space. Until then, consider the following phased approach.
The following options for validating the output of CVSS calculator implementationsare ranked from most comprehensive to least comprehensive.
If you discover an error in any of the implementations, please contact theCVSS SIG as well as the maintainer of the helper libraries so that we can assistin correcting any errors.
See theFIRST CVSS resources repofor python code to generate these vector strings as described below.
See theFIRST CVSS resources repofor documents that contain the sets of vector strings and the resulting correct scores as described below.
The Reference Set
In thegithub repo, this is a setof diverse metrics using each vector value across the range of metrics. This is arepresentative set of metrics that should test each equivalent set and is the mostcomprehensive test of calculator output, short of testing the full metric space.
This set of data is comprised of roughly fifty thousand records of full validmetric strings, representing each equivalent set. There are also a number ofnegative tests that include invalid strings as well as strings that are validbut should return zero from the calculator.
This data can be used to extensively check any calculator implementation output.Use this reference set to verify your own calculator output against the data in theset compiled from the official calculator.
Base and Threat
If you are a vendor, in all likelihood you only want to provide v4 vectors usingCVSS base or possibly base and threat vectors. In the repo there is some simple codeto generate the full set of roughly 100,000 base scores, or 400,000 base plus threatscores. The data set also exists as a standalone set of vectors as well as vectorsand the resulting score which can be used to check the output of your calculator implementation.
Equivalent Sets
As part of the CVSS v4 math, the CVSS SIG combined metric vector strings into 270 sets.The easiest method to test your calculator is using this set, the highest order set ofvectors for each set.
List of Calculator Libraries
Below is a list of libraries providing CVSS scoring functionality. The CVSS SIGmakes no guarantees about the accuracy of the scoring output. Validate the useof these libraries with the guidance in this FAQ entry.
Origin of the official calculatorRedHatSecurity :https://github.com/RedHatProductSecurity/cvss
Other ports(JavaScript/TypeScript) pandatix :https://github.com/pandatix/js-cvss
(Golang) pandatix :https://github.com/pandatix/go-cvssAPI implementation of the official calculator, by Akshat Vaid:https://github.com/akshatvaid/cvss-v4-node-api
(Rust) emocrab :https://github.com/emo-crab/nvd-rs/tree/main/nvd-cvss(Python) Benjamin Edwards :https://github.com/bjedwards/cvss4py(Typst) Drake Axelrold :https://github.com/DrakeAxelrod/cvss.typ(Perl) Giuseppe Di Terlizzi :https://github.com/giterlizzi/perl-CVSS
How can I apply CVSS concepts to AI / LLM application issues?
There have been questions about using CVSS to evaluate issues in generative AIand other LLM applications. CVSS is designed to be used to evaluate the impact ofcybersecurity vulnerabilities, impacting the confidentiality, integrity, or availabilityof data within an information system. Seethe vulnerability definition in the CVSS User Guide.
Analysts can typically apply CVSS to certain classes of cybersecurity vulnerabilitiescommonly seen in such applications, such as model poisoning, denial of service, orinformation disclosure. CVSS may not work well for issues like model inversion, inference,or prompt injection that do not have measurable impacts and relate more to bias, ethics, or legal issues.
Vulnerability analysts need to consider the security policy, threat model, and intended useof the application. Many current generative AI applications cannot presume to be totally safefrom certain classes of attacks, and the usage policy reflects this. Warnings to verify output of LLMsare present in many usage policies.
While a security policy may state that the model state should be private, current applicationscan’t always be made to withstand model inversion. While this would be a violation of the policy,and thus an impact, analysts should consider that with the current design of applications, it is difficult to prevent model inversion. SeeDiscover ML Model Ontology in Mitre ATLAS.
Model safety restriction bypass or prompt injection are viewed typically as a configuration weakness,similar to a web server configuration flaw. SeeEvade ML Model andLLM Prompt Injection on Mitre ATLAS.
AI Vulnerability Scoring Rubric
1. Are there measurable confidentiality, integrity, or availability impacts? Especially to the infrastructure or underlying application?
Use CVSS according to those measurable impacts.
2. Are model outputs incorrect, biased, or potentially harmful?
If there are confidentiality impacts, compare against usage policy and the security model.
CVSS is designed to score cybersecurity vulnerabilities. The CVSS SIG acknowledgesthe importance of tracking ethical or legal risks which in risk management languageare also caused by vulnerabilities, but are not cybersecurity vulnerabilities.CVSS should not be used to score ethical or legal vulnerabilities.
3. Are model outputs confined to a single user?
With no reflected outputs, there are no impacts to the integrity or availability of the application.
What are best practices for vulnerability assessments that differ depending on the platform?
Complex systems often include third-party libraries and other components. Vulnerability impacts in these libraries can change from one system to the next based on how those libraries are used. Library maintainers set CVSS Base metrics that correspond to a worst-case compromise of the library in a general sense. However, vulnerability assessments in vulnerability databases that relate to specific CVEs may not be appropriate for all platforms.
Vendors who include libraries in their products may indicate vulnerability impacts from those libraries in a variety of ways. Commonly, vendors include lists of libraries within their product and use the original vulnerability assessment from the package maintainer or coordinating disclosure organization. Such lists may use structured, machine-readable formats such as Vulnerability Exploitability eXchange (VEX) to facilitate scalable and interoperable communication of this information. When that original assessment is included, it communicates a potential worst-case impact assessment. CVSS assessments for any given CVE may not apply to all systems that include a library that is affected by that CVE. System maintainers who use those libraries are encouraged to re-evaluate and change CVSS Base metrics to generate a new CVSS Base vector that accounts for system mitigations. This new assessment should include a new CVSS Base score and describe how the library vulnerability impacts the product. Configuration, least privilege principle, and other platform mitigations may change the resulting assessment.
Consumers of CVSS assessments should use information that is as relevant to their end platform level as possible. Consumers should also be the only ones in the vulnerability assessment process to apply Environmental metrics, per Section 1.2 of the CVSS Specification Document. Library or system maintainers must not use Environmental and Threat metrics because they are expressly reserved for consumer organizations that have deployed libraries directly or within complex systems. Consumer organizations are responsible for selecting the CVSS Base score (vector string) that best matches their use case, which may be direct use of the library or deployment as part of a complex system. The Environmental and Threat metrics must be applied to this chosen vector string for a final score that reflects the local deployment.
Vulnerability Assessment Rubric
1. Obtain the vulnerability assessment from the library maintainer
2. Obtain the product assessment, if any, from vendor product owner
3. Apply Threat and Environmental metrics to the most relevant assessment
How should threats be assessed using the Exploit Maturity metric?
Practically, the Exploit Maturity metric intends to capture the anticipated frequency ofattacks against the vulnerability. The anticipated frequency of attacks targeting thevulnerability aids decision making by CVSS consumers. However, many threat scenariosdo not fit so cleanly into a specific metric, and the limited number of available metricsmeans certain compromises.
The most severe metric, Attacked, includes in its description the existence of highlyspecialized exploit code. This means that in some corner cases, the mere existence of aMetasploit module would equate CVSS Exploit Maturity to Attacked, even in theabsence of positive attribution of in-fact attacks targeting the vulnerability. However, itnaturally follows that if highly specialized exploit code exists, threat actors will use thatcode.
Specialized exploit code that is privately held by threat actors, while not observable,also represents a significant increase to the potential frequency of attacks and shouldalso be considered for the Attacked metric. Assessors are responsible for theassertions that they make in provided CVSS vectors, and CVSS consumers must have acertain amount of trust in their scoring providers.
Exploit code created by vendors that will never become public should generally beassessed as Unproven. Although the vendor owner demonstrated capabilities, knowledgeof that is not known publicly. Functional exploits or solutions to simplifyexploitation of the vulnerability by software and product vendors owners, or testingteams working for those vendor owners, is not intended to be included in the ExploitMaturity: Attacked metric value.
How can CVSS v3.1 vectors be derived from v4.0 vectors?
CVSS users have asked for methods to generate CVSS v3.1 vectors from CVSS v4.0 vectors tosimplify assessments and ease adoption. The CVSS v4.0 vector contains clearer assessment datathan CVSS v3.1.
However, if you do want to generate CVSS v3.1 vector strings from CVSS v4.0 vectors, doit programmatically. The SIG offers asimple script (cvss_reverse)to process vectors following logic that complies with the CVSS standard.
Conversion rubric enforced by the simple script:
- Exploitability metrics largely map 1 to 1.
- For impact metrics, take the highest CIA impact of vuln. / subs. system from the v4.0 vector.
- If they are the same equivalency set, use vuln. system impact metrics.
- If there is subsequent system impact in at least one CIA metric, then mark v3.1 Scope:Changed. Otherwise mark Scope:Unchanged.
Do not combine impacts in vectors from CVSS v4.0 when converting to CVSS v3.1. The impact metricsshould represent either the impact to the vulnerable component or the subsequent component, not a combination.
Per the CVSS v3.1 Specification Document:However, if a scope change has occurred, then the Impact metrics should reflect the Confidentiality, Integrity, and Availability impacts to either the vulnerable component, or the impacted component, whichever suffers the most severe outcome.
Version History
| Date | Ver | Description |
|---|
| 2023-11-01 | v1.0 | Initial Publication |
| 2024-02-12 | v1.1 | Added FAQ on Attack Requirements and system configuration |
| 2024-07-19 | v1.2 | Added FAQ on CSRF and Why of the Math |
| 2024-08-27 | v1.3 | Added FAQ on Calculator Guide and AI / LLM concepts |
| 2025-03-14 | v1.4 | Added FAQ on CVSS vector reassessment |
| 2025-11-14 | v1.5 | Added FAQ on Exploit Maturity |
| 2026-01-29 | v1.6 | Added FAQ on Deriving v3.1 Vectors |
IEC 61508 - Wikipedia ↩
A “worm” is a “A computer program that can run independently, can propagate a complete working version of itself onto other hosts on a network, and may consume system resources destructively.” (RFC 4949). ↩
CVSS v4.0 Specification Document, Section 6 ↩
