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.
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:
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.
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.
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.
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.
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.
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.
This version highlights that the CVSS is designed to measure the severity of a vulnerability and, therefore, must not be used as the only tool to assess risk. The CVSS v3.1 specification document now clearly states that the CVSS Base Score represents only the intrinsic characteristics of a vulnerability that are constant over time and are common to different user environments. To carry out a systematic risk analysis, this base score must be complemented with a contextual analysis taking advantage of the temporal and environmental metrics, and with other external factors not considered by the CVSS as exposure and threat.
A minor update to CVSS was released on June 17, 2019. The goal of CVSS version 3.1 was to clarify and improve upon the existing CVSS version 3.0 standard without introducing new metrics or metric values, allowing for frictionless adoption of the new standard by both scoring providers and scoring consumers alike. Usability was a prime consideration when making improvements to the CVSS standard. Several changes being made in CVSS v3.1 are to improve the clarity of concepts introduced in CVSS v3.0, and thereby improve the overall ease of use of the standard.
The CVSS is one of several ways to measure the impact of vulnerabilities, which is commonly known as the CVE score. The CVSS is an open set of standards used to assess a vulnerability and assign a severity along a scale of 0-10. The current version of CVSS is v3.1, which breaks down the scale is as follows:
PlexTrac is pleased to announce the release of the CVSS v3.1 calculator and the addition of CVE and CWE data fields across the PlexTrac platform. This feature will help make reporting and remediation efforts even quicker and easier.
You can now handle all CVSS v3.1 calculations, including environmental and temporal calculations, inside of PlexTrac. In addition, there are new fields for CVE and CWE data that will streamline workflows. With these new features you can
The new version aims to address and correct a common mistake where the CVSS Base Score was seen as the only factor for assessing risk, rather than a comprehensive risk assessment system. The main changes in v3.1 clarify the definitions of base metrics such as Attack Vector, Scope, Privileges Required, Security Requirements and more definitions.
In order to ensure a consistent scoring standard across all industries, changes to the CVSS v3.1 include clarification of the definitions and explanation of existing base metrics, an expanded and refined version of the CVSS Glossary of Terms as well as the CVSS Extensions Framework. This is a new standard method of extending CVSS that allows a scoring provider to include additional metrics and metric groups while retaining the official Base, Temporal, and Environmental Metrics.
While the change in CVSS scoring may seem minimal and cumbersome, CVSS v3.1 can have a big impact. It provides users with a more comprehensive and precise context and shared understanding. The updated standard affects not only the CVSS score but also the way we assess our risk and address security vulnerabilities.
The US National Infrastructure Assurance Council (NIAC) developed CVSS and the standards to measure the impact of severity in an IT environment. CVSS is an open framework, so organizations have access to the measuring criteria used to create scores, enabling everyone to have a clear understanding of the vulnerability scores.
If you have encountered an unlisted security vulnerability or other unexpected behaviourthat has security impact, or if the descriptions here are incomplete, please report themprivately to the Log4j Security Team.Note that reports assuming attacker's access to the Log4j configuration will not qualify as a vulnerability.Thank you for your understanding and help!
CVSS scores provide more detail as to why a vulnerability is considered to have a given severity (such as, critical, high, medium, or low), with a numerical score from 0.0 to 10.0. This looks at individual dimensions of the vulnerability itself, to see how easy it would be to exploit, and what the potential impact of exploiting it would be on the application. For example, a vulnerability that leads to remote code execution, one of the worst potential impacts, would have a high CVSS score and therefore a high severity. GitHub uses CVSSv3.1 to calculate CVSS scores.
A Python 3 library for calculating CVSS v2, CVSS v3 and CVSS v3.1 vectors, with tests. Examples on how to usethe library is shown below, and there is some documentation on the internals within the docs directory. The libraryis designed to be completely extendable, so it is possible to implement your own custom scoring systems (or those of your clients)and have it work with the same API, and with the same bells and whistles.
It's pretty simple to use. cvsslib has a cvss2, cvss3 and cvss31 sub modules that contains all of the enumsand calculation code. There are also some functions to manipulate vectors that take these cvss modulesas arguments. E.G:
There are some powerful mixin functions if you need a class with CVSS members. These functionstake a cvss version and return a base class you can inherit from. This class hassome utility functions liketo_vector() and from_vector() you can use.
Once you define this you can pass your super_scores module to anycvsslib function like calculate_vector or django_mixin and it willall just work. You can even serialize the data to and from a vectorif you define the correct vector: X in the enum docstrings.
d0d94e66b7