How the CVSS vulnerability rating system works

Ruslan Rakhmetov, Security Vision

In a world where new cyber threats appear daily, information security professionals need a universal and understandable tool for risk assessment. How can you determine which of the hundreds of vulnerabilities in your system require immediate attention and which can wait? To answer this question, the CVSS (Common Vulnerability Scoring System) standard was created - a generally accepted vulnerability severity assessment system, which we will discuss in this review.

CVSS is not just a set of numbers, but an open standard that allows IT professionals, security researchers, and developers to speak the same language. It provides a transparent and objective scale for assessing software vulnerabilities, helping to prioritize tasks to eliminate them.

Whether you are an experienced information security professional or just starting your journey in IT, this guide will help you understand and effectively use CVSS to protect your digital assets. The CVSS standard did not appear out of nowhere. Its development was a response to the urgent need for a unified vulnerability classification system: the idea was born in 2003-2004 within the NIAC ( National Infrastructure Advisory Council ), which advises the US President on national infrastructure security. The first version, CVSS v1, was introduced in 2005, and then the non-profit organization FIRST (Forum of Incident Response and Security Teams ) has become the main driver of progress in the development of this assessment. Since 2007, FIRST has been the custodian and main developer of the standard, ensuring its independence and openness. We will not go into much history, but we will emphasize that the standard is still evolving, in 2023 CVSS v4.0 was released.

The primary source of CVSS scores for common vulnerabilities (CVE) is the US National Vulnerability Database (NVD). Each CVE page in NVD contains the assigned score and vector string for different CVSS versions. In early 2024, NVD experienced significant delays in data analysis and enrichment, but the situation began to improve thanks to cooperation with the US Cybersecurity and Infrastructure Security Agency (CISA). In Russia, the FSTEC Threat Database (FTSEC) and the vulnerability calculator for the most current version 4 are additionally used .

Having analyzed the history of its origin and the main sources of information, we will move on to an analysis of what constitutes a vulnerability severity assessment (a number from 0 to 10), which is formed on the basis of a set of characteristics grouped into three groups of metrics. Each group answers its own question:

   1) Base describes what are the internal properties of the vulnerability? This is its constant characteristic.

   2) Temporal group describes what is currently known about this vulnerability? This parameter may change over time, for example, Security analysts Vision updates the database of trending vulnerabilities daily, which allows them to adapt and use new knowledge.

   3) The contextual ( Environmental ) group contains the parameters that will "tell" how dangerous this vulnerability is for our system? These parameters depend on the environment and infrastructure.

The Base Metrics Group is the core of the standard, based on the metrics of which the Base Score is calculated, which you most often see in security bulletins (for example, from NVD). Imagine that a vulnerability is the ability to illegally enter someone else's summer house (condemned and punished by law, but we use this analogy for educational purposes). Then, exploitability metrics describe how exactly this can be done and what is needed for this.

   -   Attack vector ( Attack Vector ) describes how an attacker can exploit a vulnerability. For example, the network (N) vector, when an attack is possible through the network, is recognized as one of the most dangerous options. The opposite is the physical (P) vector, when physical access to the equipment is required. Two more vectors, adjacent network (A) and local (L), correspond to vulnerabilities that require access to the same local network (physical or logical) or local access to the system (for example, via the console or SSH).

In our analogy, the attack vector will describe how a thief gets into a house. If a thief, sitting in his office, hacks into the smart home system via the Internet and opens the door remotely, this is a network vector. If he simply knocks down the door with his shoulder or a crowbar, i.e. the burglar needs direct physical impact on the house, the vector will be physical. When the thief is already standing on your property (for example, he got in through the gate) and picks the key to the door lock. If he needs access to your property (a "local machine" in terms of IT systems), the description will be a local vector, and if he only climbs over the fence from a neighboring property, i.e. is in close proximity (in the "same network" with the house), it is an adjacent attack vector.

   –   Attack Difficulty (Attack Complexity is divided into low and high, when, for example, special conditions are not required and the vulnerability can be exploited "head-on" or when factors beyond the attacker's control (for example, the need to guess the session token or conduct a "man in the middle" attack) become greater.

   –   Answering the question, what is the level of access/privileges (Privileges Required) is needed by the attacker before exploitation begins, analysts distinguish 3 options: when privileges are not required (i.e. any unauthorized user can carry out an attack), when they are low (basic user rights) or high (administrator rights).

Difficulty can be described in the same analogy: if the door of the house is not locked or the key is under the mat, i.e. no special skills or conditions are required - the difficulty will be low. But if the lock opens only when a train passes by, and the vibration somehow affects the lock in the door (it is difficult to imagine this, but in general, success depends on external conditions beyond the thief's control) - the difficulty will be high.

   –   Impact Metrics​ Metrics ) assess the impact of a successful attack on the three pillars of information security: confidentiality (Confidentiality, C), integrity (Integrity, I) and availability ( Availability , A). The same scale (no impact, low and high) is used for each of these three metrics.

The influence metric answers the question "What does a thief need in advance?": if there is no fence around the site, the door is open and any passerby can enter - the influence is zero, i.e. absent. The basic level of access will be a situation when the thief has a key to the gate to get into the site, and a high level - when he has a key to the owner's alarm (the conditional password of the IT system administrator).

   –   Vulnerabilities sometimes also interact with the user (User Interaction). The vulnerability can be fully automated (when no action is required) or when the victim must perform some action (for example, follow a malicious link, open an infected file).

If the thief does everything himself: enters the house at night, when the owners are asleep or absent - he does not need the participation of the owner (user). If he rings the doorbell under the guise of a plumber, and the owner lets him in himself (the victim must perform an action for the attack to succeed) - the vulnerability requires the participation of the "user").

The base score is static. But the real world changes: working exploits appear, patches are released. A temporary group of metrics adjusts the base score taking these factors into account. Let's move away from the topic of robberies and consider another situation when ants appear in your house. This will be our "vulnerability".

   –   If there is already public code to exploit the vulnerability , the availability of the exploit is determined. In the vulnerability management module and security scanner Security Vision exploit availability is determined by the classic scale: if the exploit is unavailable, the score does not change; if there is a working exploit, the metric becomes working. A high level will be a situation when an automated turnkey exploit or malicious software from attackers is available. The more accessible the exploit, the higher the final score.

How well the ants have studied the way to your sugar will describe the level of the exploit: if you accidentally saw a single scout ant on the wall (it seems to have gotten lost and there is no systemic threat yet) - the exploit is not confirmed. If the scout ant has found your sugar bowl and left a pheromone trail (now a dozen other ants are following this trail) - a working "route" for exploitation has appeared. And the situation in which the ants have already laid a full-fledged, busy "highway" from their anthill outside the window straight to your kitchen (they are coming in a continuous stream, and the problem has become widespread and automated) - the exploit has become more serious.

   –   Remediation Level determines whether the means to eliminate the vulnerability are available: if the solution is unavailable, the assessment also does not change, if there is a "cheat" in the language of programmers - an unofficial solution is recognized. If the vendor of the vulnerable program has released a temporary patch, the assessment becomes temporary, and the presence of an official fix reduces the final assessment. By the way, the capabilities of auto-patching vulnerabilities are also included in the SV vulnerability management module VM .

You start to analyze what means of fighting ants you have. If you do not know where they are coming from and what to do with them, there is no solution. When you read on the Internet that you can wipe their path with vinegar to destroy the pheromone trail, you start to use a "crutch" (a temporary measure that may help, but does not solve the problem radically), and if you bought a regular insect spray in the store and sprayed it in the corner where they appear, consider that you have applied a temporary patch that will scare them away for a couple of days, but will not destroy the anthill. The official level will be when you called a professional exterminator: he found the anthill, destroyed it and sealed all the cracks through which the ants could get into the house. The problem is completely solved.

   –   Report Confidence describes how confirmed the information about the vulnerability is. It can be unknown, reasonable (when there are unconfirmed messages, for example, in expert blogs) or confirmed (when the vendor has confirmed the presence of the vulnerability and thus shows that it is working on eliminating the problem).

Now let's turn to the question of how sure you are that the ant problem really exists. Let's imagine that you thought you saw a speck of something flash across the kitchen table (maybe an ant, maybe just a speck of dust). This means that you are not sure that the problem exists. If your neighbor complained that ants appeared in his kitchen (most likely, you will have them soon too) - there is good reason to believe that the problem is real. The problem is confirmed at the moment when you see with your own eyes a clear path of hundreds of ants heading towards the sugar bowl. The existence of the "vulnerability" is beyond doubt.

Using time metrics allows you to get a more realistic picture of the threat at the moment. But the third group of metrics, contextual, is the most flexible and the most important for a specific organization: it allows you to adapt the assessment to the unique conditions of your IT infrastructure. In essence, you answer the question: "What does this vulnerability mean for us?" It is the contextual assessment that gives the most accurate idea of the real risk and helps to effectively allocate resources to eliminate it.

Here you can override any of the base metrics. For example:

   –   Modified Attack Vector (MAV): If the vulnerability has a "Network" vector (AV:N), but the vulnerable server is in an isolated network segment with no outside access. You can change the MAV to "Local", and the severity score will drop dramatically.

   –   In addition, security requirements, your regulations and the information security tools used are added.

   –   Requirements for Confidentiality (CR), Integrity (IR), Availability (AR) can also be redefined depending on vulnerable assets (as it is arranged in the resource-service model of the Security Platform modules Vision). How important is a specific asset to your business? A vulnerability in a server with public marketing materials and the same vulnerability in a server with a customer database will have a different final score.

Common Vulnerability Scoring System (CVSS) is a fundamental standard in any cybersecurity professional's toolbox. It provides a universal, transparent, and structured language for classifying and assessing the severity of software vulnerabilities.

We've shown how to get the most accurate picture by going beyond a basic assessment. Using time metrics allows you to understand the relevance of a threat, and contextual metrics allows you to tailor it to the realities of your IT infrastructure. The new version of CVSS v4.0 makes this process even more flexible and detailed.

Remember that CVSS is a powerful prioritization tool, but it is not a panacea. Use it in combination with other threat data and deep knowledge of your own systems to build a truly effective defense strategy.