CVSS: The 5 biggest misconceptions in risk assessment

CVSS: The 5 biggest misconceptions in risk assessment

CVSS: The 5 biggest misconceptions in risk assessment

The Common Vulnerability Scoring System (CVSS) is an established standard for assessing vulnerabilities. CVSS is used by default to assess known vulnerabilities in the Common Vulnerabilities and Exposures (CVE) database and is also used to assess vulnerabilities resulting from a pentest.

In this blog entry, I would like to clarify 5 misconceptions that are often misunderstood in practice. The blog entry is based on CVSS 4.0 and references some technical terms that have been around since v4.0 (e.g. CVSS-BT instead of Temporal Score, Threat Metrics, Exploitability Metrics). In principle, however, the statements also apply to CVSS 3.0 and 3.1.

Misconception #1: The CVSS score represents the risk

According to the standard, the CVSS score does not explicitly evaluate the risk, but rather the technical severity of a vulnerability. What does that mean exactly?

CVSS only considers the "technical impact", not the "business impact"

CVSS looks at the technical impact on the confidentiality and integrity of the data as well as the availability of the system. The resulting consequences for the individual situation of a company and its business processes are not evaluated. The official CVSS documentation lists the following criteria, for example, which must also be considered: "[...] regulatory requirements, number of customers impacted, monetary losses due to a breach, life or property threatened, or reputational impacts". (1)

CVSS does not assess the likelihood of an attack

Even without business impact, CVSS could still determine the technical risk? To do this, the probability of a vulnerability being exploited would have to be taken into account (risk = probability * severity). However, CVSS does not sufficiently consider the probability because important factors are missing. According to the standard, the CVSS base score in particular should deliberately only evaluate factors that are independent of the time component and the individual context or environment in which the vulnerability is located. This is the only way that a CVSS score can be applied to all companies at all times. For example, the following factors that would be necessary for the consideration of a probability are missing:

  • Accessibility of the system from the internet vs. intranet (Fun Fact: Intranet does not mean Adjacent for Attack Vector)
  • Size of the potential attacker group
  • Relationship of trust with the attacker group (employees vs. customers)
  • Difficulty of finding the vulnerability
  • Degree of awareness of the vulnerability

So what does CVSS assess in the Exploitability Metrics?

The factors that CVSS takes into account look more at the technical requirements or the technical exploitability of a vulnerability. The factors for exploitability (e.g. Attack Complexity, Privileges Required and User Interaction) also have little influence on the CVSS score. This is because CVSS focuses on severity, as the following example illustrates:

We have a vulnerability for which at least 2 of the CIA factors are rated as high in the impact metrics. In this case, this concerns the confidentiality and integrity of the data. The CVSS base score is therefore 9.3. (2)

Condition 1:
The exploitation of the vulnerability is very complex and other conditions must be met. For example, the attacker must first crack an AES encryption and a race condition must be fulfilled, but the attack cannot be automated. In this case, the factors "Attack Complexity" and "Attack Requirements" are both High. What impact does this have on the CVSS base score? Almost none: 9.2 (3 )

Condition 2:
The vulnerability is only accessible in the admin panel of an application (Privileges Required = High). The application is only accessible from the internal network (cannot be displayed). The application is also only accessible via a jump server (Attack Vector = Adjacent). What impact does this have on the CVSS base score? Minor: 8.5 (4)

In fact, with the CVSS base score, it is not possible to downgrade a vulnerability to medium (<7.0) as soon as at least 2 factors are rated high at CIA, regardless of how the exploitability metrics are rated. Other risk models, such as the OWASP Risk Rating, would still provide for an overall risk of medium even with a high severity level, provided the probability is low. However, CVSS does not assess probability.

Figure: Risk matrix according to OWASP (5)


When using the CVSS base score, it is important to know that the focus is on the technical severity. The impact on the business and the probability of the vulnerability being exploited are not sufficiently assessed.

Note: The CVSS-BTE score also considers the threat level (Threat Metrics, formerly Temporal) as well as the individual security requirements of the customer (Environmental). The CVSS standard itself says: "[...] the resulting CVSS-BTE score can be considered much closer to "Risk". (6)

Misconception #2: CVSS is suitable for the evaluation of all pentest findings

The advantages of CVSS are obvious: a transparent, comprehensible, standardized and also customizable assessment of vulnerabilities is important and valuable. CVSS offers all of this. However, CVSS also has two major disadvantages for the evaluation of pentest findings.

  • CVSS does not distinguish between exploitable vulnerabilities and hardening measures.
  • CVSS (and CVSS 4.0 in particular) assumes published vulnerabilities

Hardening measures rated too low or too high

Usually, not only vulnerabilities but also hardening measures are reported in a pentest or other security assessments. Hardening measures cannot be exploited directly, but they make an attack more difficult if another vulnerability is exploited. Examples of this are information leakages of version numbers, the lack of use of TLS 1.3 or additional protective measures such as 2FA for OWA (Outlook Web App) and Applocker on Windows systems.

These are findings that cannot be exploited in themselves or are the cause of attacks. However, the associated measures can make attacks more difficult if they are implemented.

Such hardening measures either have no severity level in CVSS (CIA = None) and would therefore have a CVSS score of 0 or are given a low severity level (CIA = Low), which often results in a CVSS score of between 4 and 6. This puts such hardening measures on a par with exploitable vulnerabilities such as XSS and would sometimes be rated far too high. Traceability is also lost because it is no longer clear why the absence of TLS 1.3 now has an impact on confidentiality. In most cases, it is more of a compliance issue.

New with CVSS 4.0: unpublished vulnerabilities are generally rated very low

A pentest usually identifies vulnerabilities that are subsequently reported confidentially to the customer but not published. The CVSS base score is applicable to both published vulnerabilities and unpublished vulnerabilities. The application of the base score is therefore practicable in both cases.

However, if you now want to evaluate the BT score (Threat Metrics, formerly Temporal) and thus the susceptibility to an exploit, CVSS 4.0 brings an exciting change. The Threat Metrics introduced there has a greater influence on the overall score, but only takes into account published proofs of concept. This means, of course, that the vulnerability must already be publicly known. As this is rarely the case with pentests, pentest findings could in principle be downgraded significantly, regardless of how easy it is to find the vulnerability (as we know, the CVSS does not take this into account).

It remains to be seen how the BT score will be used in practice for unpublished pentest findings and what impact it will have.


Ultimately, it depends on the type of pentest or security assessment. If the focus is on exploitable vulnerabilities, CVSS is a suitable evaluation scheme for the severity level. If hardening measures are also to be assessed, CVSS is only suitable to a limited extent and a decision should be made as to how such findings can be considered in a differentiated manner.

When using CVSS 4.0, the use of the CVSS-BT score should be evaluated internally and a clear decision made as to how and whether it should be used for unpublished vulnerabilities.

Misconception #3: The CVSS score can be used to prioritize vulnerabilities

The CVSS base score should not be used directly to prioritize measures. Rather, it indicates what could happen from a technical perspective. The following aspects should be taken into account when prioritizing:

  • When evaluating hardening measures, an internal reassessment of the risk and cost-benefit ratio should be carried out. This is because we have already learned that CVSS does not sufficiently consider pure hardening measures.
  • The CVSS base score should be supplemented with the CVSS BTE score (Threat and Environmental Metrics) by the customer in order to be able to view the vulnerability in a specific context. When using CVSS 4.0, the use of the CVSS BT score must be evaluated internally in advance, see #2. The BT score must be calculated regularly if it is used to prioritize vulnerabilities.
  • The CVSS score must be used to derive the actual and concrete risk for the company. In addition to the CVSS BTE score, it is advisable to consider other factors for the probability of exploitation and for the business impact that are not taken into account by CVSS.

CVSS requires post-processing for your own situation and assessment of the specific risk in order to derive a prioritization. If the CVSS-BT score is used for deprioritization, it must also be recalculated regularly to rule out the risk of underrated vulnerabilities.


Misconception #4: The CVSS score is calculated exclusively by the service provider

There are usually 3 parties involved in the assessment of CVSS

  • Security researcher: reports a vulnerability to the manufacturer (supplier)
  • Supplier : He owns a product in which the vulnerability is located
  • Consumer: uses the product in which the vulnerability is located

The CVSS standard stipulates that only the CVSS base score is calculated by the "supplier" or "security researcher". The CVSS-BT and CVSS-BTE score must be calculated by the consumer, i.e. usually the customer, as the individual context of the environment and the current point in time are taken into account. This means that the customer can use CVSS-BTE to incorporate the individual security requirements for the product and the current threat level for the vulnerability at the time of the assessment.
Note: If the additional factors in the BT and BTE score (e.g., Exploit Maturity) are not evaluated, a "Not-Defined" always corresponds to the highest value (e.g., Security Requirements = "High" and Exploit Maturity = "Attacked"). As a result, the CVSS base score can only be corrected downwards by the other factors.


CVSS requires the customer to calculate the CVSS BTE score in order to be able to view the vulnerability in an individual context.

Misconception #5: CVSS offers a fine-grained assessment

The different factors ensure that several relevant aspects are taken into account when assessing vulnerabilities. However, CVSS is not always particularly flexible in the assessment of the individual factors. For example, when assessing the severity level and the associated confidentiality, integrity and availability, there is only a choice between "None", "Low" and "High". You therefore have to choose between a low or high severity level. Cross-site scripting is therefore often rated just as highly for confidentiality as the existence of a software version number in the HTTP header. The situation is similar for "Attack Complexity" and "Attack Requirements". These can also only be "low" and "high".


Sometimes one would like to see a gray area in the evaluation instead of having to choose between black and white in order to be able to better differentiate between different vulnerabilities.



CVSS is a very good tool for extracting the vulnerabilities with the highest severity from known vulnerabilities, identifying the need for action and then determining the specific risk for the vulnerability in your own environment. Further information such as the EPSS score (Exploit Prediction Scoring System) can also be helpful here. (7 )

However, for use with unknown and unpublished vulnerabilities, it is also important to know the limits of CVSS in order to derive the right priorities and measures.
We - the fernao security force - will be happy to advise you on how to apply CVSS in your company and derive specific risks from it or switch to alternatives for risk assessment. We would also be happy to show you how we implement the risk assessment in our pentests .



1 - → Introduction
2 -
3 -
4 -
5 -
6 - → Chapter 2.2 - Further information on this under point 4
7 -

< Zurück zur Übersicht
Home | CVSS: The 5 biggest misconceptions in risk assessment