What is the Common Vulnerability Scoring System (CVSS)

The Common Vulnerability Scoring System (CVSS) is a standardised framework for measuring how severe security vulnerabilities are in software and computer systems. It assigns each vulnerability a score between 0.0 and 10.0, where higher numbers mean more dangerous security flaws. Think of it like a universal temperature scale for security risks—instead of everyone describing vulnerabilities with vague terms like “serious” or “moderate,” CVSS gives security teams a consistent way to talk about which threats matter most.

If you’ve visited our site with concerns about a potential ransomware incident and are unsure how to deal with it, contact Zensec immediately. Our rapid cyber incident response teams are available 24/7 to contain infected systems, protect your critical assets, and start the recovery process.

Where Does The CVSS Come From

When security researchers discover a new software vulnerability, they face an immediate challenge: how do you communicate its severity in a way that’s consistent, comparable, and actionable across different organisations and industries?

Without a standardised measurement system, one vendor might call a flaw “critical” while another labels a similar vulnerability “moderate,” leaving security teams struggling to decide what to fix first.

The Common Vulnerability Scoring System (CVSS) solves this problem by providing a universal framework for measuring vulnerability severity.

It assigns each security flaw a numerical score between 0.0 and 10.0, along with detailed metrics that explain exactly why that score was assigned—giving security professionals a common language for discussing and prioritising threats. In this article, you’ll learn how CVSS works, what the different metrics measure, how scores are calculated, and how to use this framework effectively while recognising its limitations.

How The CVSS Works

CVSS is an open framework maintained by the Forum of Incident Response and Security Teams (FIRST), a global organisation that helps coordinate responses to cyber incidents. The system produces two key outputs: a numerical score and something called a vector string, which is basically a compressed code that shows exactly how the score was calculated.

The framework breaks down into four metric groups. Base metrics capture the unchanging characteristics of a vulnerability—things like how easy it is to exploit and what damage it could cause. Threat metrics (called Temporal metrics in older versions) track factors that change over time, like whether hackers have already created working exploit code or if the software vendor has released a patch. Environmental metrics let you customise the score based on your specific situation—maybe you’ve got extra security controls in place, or perhaps the vulnerable system handles extremely sensitive data.

Here’s what makes this layered approach useful: a vulnerability doesn’t have just one fixed score. The base score might be 7.5, but that number can shift higher if exploit code suddenly appears on GitHub, or lower in your environment because you’ve isolated the affected system behind multiple firewalls.

CVSS metrics

CVSS metrics evaluate vulnerabilities across three main dimensions: Exploitability, Scope, and Impact. Each dimension answers a different question about the vulnerability.

Exploitability asks: how hard is this to pull off? A vulnerability that anyone can exploit remotely over the internet without needing a password gets a high exploitability score. Compare that to a flaw that requires physical access to the server and administrator credentials—far fewer attackers can realistically pull that off. This metric essentially measures your attack surface, or how exposed you are to potential exploitation.

Scope looks at whether an attacker who exploits the vulnerability can break out and affect other systems. Imagine a vulnerability in your web application that also lets attackers compromise the database server sitting behind it. That’s a scope change, and it makes the vulnerability more dangerous because one breach can cascade into multiple compromised systems.

Impact examines the potential damage across three areas:

• Confidentiality: Can attackers access data they’re not authorised to see?
• Integrity: Can they modify or delete data without permission?
• Availability: Can they disrupt or take down services?

A vulnerability that could expose your entire customer database scores high on confidentiality impact. A flaw that could bring down critical systems scores high on availability impact. The worst vulnerabilities hit all three areas.

CVSS score

A CVSS score condenses all the various metrics into a single number between 0.0 and 10.0. The calculation uses mathematical formulas that weigh different factors, with exploitability and impact metrics carrying the most weight.

The scoring process starts with base metrics, which produce the base score—the foundation of every CVSS assessment. From there, threat metrics can modify this base score to reflect current conditions. Finally, environmental metrics can adjust the score further to match your organisation’s specific risk exposure.

CVSS maps numerical scores to severity ratings that make communication easier:

• None (0.0): No vulnerability exists
• Low (0.1–3.9): Minimal risk, typically hard to exploit or limited damage
• Medium (4.0–6.9): Moderate risk that deserves attention but not panic
• High (7.0–8.9): Significant risk that warrants prompt action
• Critical (9.0–10.0): Severe vulnerabilities demanding immediate response

These severity bands help you quickly communicate risk levels to executives or other teams. However, the numerical score gives you more precision when you’re prioritising among multiple vulnerabilities in the same category.

CVSS Score Range	Severity Level	Meaning
0.0	None	No security impact or no vulnerability present
0.1 to 3.9	Low	Limited impact, difficult to exploit, minimal disruption
4.0 to 6.9	Medium	Noticeable risk that requires timely remediation
7.0 to 8.9	High	Significant risk with serious potential impact
9.0 to 10.0	Critical	Severe threat requiring immediate response

CVSS assessment

CVSS assessment begins when security researchers or software vendors discover a vulnerability and evaluate its characteristics against the CVSS framework. The assessor examines each metric and selects the value that best describes how the vulnerability behaves and what damage it could cause.

The National Infrastructure Advisory Council originally created CVSS to solve a frustrating problem: inconsistent vulnerability descriptions. Before CVSS, one vendor might call a vulnerability “critical” while another labeled a similar flaw “moderate,” making it nearly impossible for organisations to compare risks and decide what to fix first.

CVSS v4.0, the current version, includes four metric groups that capture different characteristics of vulnerabilities. Each assessment produces both a numerical score and a vector string—that compact representation of all the metric values. A vector string might look like 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. While this looks cryptic, it provides complete transparency about how the score was calculated, letting others understand or potentially adjust the assessment.

You’ll encounter CVSS scores in several places: vulnerability scanning reports, security advisories from software vendors, and databases like the National Vulnerability Database (NVD). These scores serve as a starting point for remediation decisions, though you’ll want to add context about your specific environment and business requirements.

Exploitability metrics

Exploitability metrics focus on the characteristics that determine how easily an attacker can successfully exploit a vulnerability. The assessment assumes the attacker has advanced knowledge of your system’s configuration and defenses—essentially a worst-case scenario.

Attack Complexity reflects conditions beyond the attacker’s control that must exist for exploitation to work. Low complexity means the attacker can expect reliable success in repeated attempts. High complexity indicates that success depends on factors like precise timing, specific system configurations, or winning a race condition. This metric doesn’t consider the attacker’s skill level or how long exploitation takes—only whether the vulnerability itself creates barriers to exploitation.

Privileges Required measures what level of access an attacker needs before they can exploit the vulnerability. A flaw requiring no authentication (like many remote code execution vulnerabilities in web applications) scores higher than one requiring administrative credentials.

User Interaction captures whether exploitation requires a human to do something, like clicking a malicious link or opening a weaponised document. Vulnerabilities requiring no user interaction pose greater risk because attackers can exploit them automatically at scale, while those requiring user interaction depend on social engineering tactics working.

Attack vector

Attack Vector measures where an attacker needs to be to exploit the vulnerability. This metric significantly influences the overall CVSS score because it directly affects how many potential attackers can reach the vulnerability.

Network-based attack vectors represent the highest severity because attackers can exploit these vulnerabilities from anywhere on the internet. A remotely exploitable flaw in a public-facing web server can be attacked by anyone, anywhere, making it accessible to the broadest possible threat landscape. These vulnerabilities often become targets for automated scanning and exploitation by opportunistic attackers.

Adjacent network vectors require the attacker to be on the same network segment as the vulnerable system—for example, on the same local area network or within Bluetooth range. While more restrictive than network-based attacks, these still represent significant risk in environments with untrusted users, like corporate offices or shared workspaces.

Local attack vectors require the attacker to have local access to the vulnerable system, either through a local account or physical access. Physical attack vectors demand that the attacker physically touch or manipulate the vulnerable component. As you move from network to physical vectors, the number of potential attackers decreases dramatically, which is why these vulnerabilities generally receive lower scores.

Attack complexity

Attack Complexity captures the effort and conditions required to successfully exploit a vulnerability beyond the attacker’s direct control. This metric distinguishes between vulnerabilities that work reliably every time and those that succeed only under specific circumstances.

Low complexity vulnerabilities can be exploited repeatedly and reliably without requiring special preparation or reconnaissance. An attacker can simply run their exploit code and expect it to work. High complexity vulnerabilities require the attacker to invest additional effort in information gathering, overcome technical barriers, or wait for specific conditions to align.

For example, a vulnerability that only works when a system is under heavy load might have high attack complexity because the attacker cannot control when those conditions occur. Similarly, a flaw that requires winning a race condition—executing malicious code in a precise timing window—represents higher complexity than a straightforward buffer overflow.

Limitations of CVSS

CVSS provides valuable standardisation, yet it has inherent limitations that can lead to oversimplified risk assessments if used in isolation. The system focuses on technical severity rather than actual risk, meaning it doesn’t account for factors like threat actor motivation, the value of affected assets, or the likelihood of exploitation in the real world.

A critical CVSS score doesn’t automatically mean a vulnerability poses critical risk to your organisation. You might have a vulnerability with a base score of 9.8 in a system that’s completely isolated from the internet, protected by multiple security layers, and contains no sensitive data. On the other hand, a medium-severity vulnerability in a critical revenue-generating system might warrant immediate attention despite its lower score.

CVSS also doesn’t capture business context or compliance requirements. A vulnerability affecting systems subject to regulatory oversight might demand faster remediation than a higher-scored vulnerability in a non-regulated environment. Similarly, CVSS doesn’t account for the operational impact of patching—sometimes remediating a “critical” vulnerability requires taking down essential services, creating a business risk that competes with the security risk.

Organisations increasingly adopt risk-based vulnerability management approaches that use CVSS scores as one input among many. This approach incorporates threat intelligence about active exploitation, asset criticality, existing compensating controls, and business impact to create a more complete risk picture.

Best practices for CVSS

Use CVSS scores as a starting point rather than the final word on vulnerability prioritisation. Combine base scores with threat intelligence to identify vulnerabilities being actively exploited in the wild—these often warrant attention before higher-scored vulnerabilities that lack exploit code.

Calculate environmental scores for your most critical systems to better reflect your actual risk exposure. This customisation helps you focus remediation efforts on vulnerabilities that pose genuine risk in your environment rather than treating all high-severity vulnerabilities equally.

Integrate CVSS into a broader risk management framework that considers asset value, threat landscape, and business impact. When you’re faced with dozens or hundreds of vulnerabilities, this contextual approach helps you answer the crucial question: “Which vulnerabilities could actually harm our organisation, and in what ways?”

If you’re facing an active ransomware incident or need expert guidance on vulnerability management and incident response, contact Zensec immediately for 24/7 support. Our NCSC-assured specialists can help you prioritise remediation efforts and recover from security incidents with minimal disruption to your operations.