What Is a CVSS Score? A Guide to Vulnerability Severity and Risk

Security and vulnerability management teams face a daily barrage of vulnerability alerts, and most dashboards rank them with a single number: the Common Vulnerability Scoring System (CVSS) score. That number decides what gets patched first, what waits, and what triggers an emergency response. But a CVSS score measures theoretical severity, not the real risk a vulnerability carries in a specific environment. A CVSS 9.8 on an isolated legacy server may matter far less than a CVSS 6.0 on a device with thousands of network neighbors, yet the score alone gives teams no way to tell the difference.

This guide explains what a CVSS score is, how it is calculated, what the severity ranges mean, and where the framework reaches its limits. It also covers how to build a risk-based approach that uses CVSS as a starting point rather than a final answer.

What Is a CVSS Score?

A CVSS score is a numerical rating, from 0.0 to 10.0, that represents the severity of a software security vulnerability. The Common Vulnerability Scoring System is a free and open industry standard maintained by the Forum of Incident Response and Security Teams (FIRST). It gives organizations a common language for describing how severe a vulnerability is, so a finding reported by one vendor means the same thing to everyone who reads it.

The higher the score, the more severe the vulnerability. A 0.0 means no severity, and a 10.0 represents the most severe rating the framework can assign. Public vulnerability sources such as the National Vulnerability Database (NVD) publish CVSS scores for known CVEs, and vendors including Cisco, Oracle, and SAP use CVSS to communicate the severity of vulnerabilities in their own products.

It is worth being precise about one point, because it shapes everything that follows: CVSS measures severity, not risk. Severity describes how technically impactful a vulnerability would be if an attacker exploited it. Risk depends on whether exploitation is likely and what the affected asset is actually worth to the business. CVSS, on its own, does not account for either.

What the CVSS Score Ranges and Severity Levels Mean

CVSS scores map to qualitative severity ratings, which is how most teams actually talk about them day-to-day. The ranges are:

• None: 0.0
• Low: 0.1 to 3.9
• Medium: 4.0 to 6.9
• High: 7.0 to 8.9
• Critical: 9.0 to 10.0

These bands are why a vulnerability gets labeled “Critical” or “High” in a scanner or a ticket. Many organizations set remediation timelines directly against them, for example, requiring that anything rated Critical be addressed within a fixed number of days. The limitation, covered later in this guide, is that a severity band says nothing about whether the vulnerability is reachable or exploitable in your specific environment.

How Is a CVSS Score Calculated

A CVSS score is derived from a set of metrics that describe a vulnerability’s characteristics. Those metrics are organized into groups, and the framework combines them through a defined formula to produce the 0.0 to 10.0 score. Every score is also expressed as a vector string, a compact machine-readable text representation of the metric values, so automated systems can ingest and compare scores at scale.

Across CVSS versions, the metrics fall into a few consistent categories:

Base metrics. These capture the intrinsic qualities of a vulnerability, the ones that stay constant over time and across environments. They include the attack vector (whether the flaw is reachable over the network or requires local access), attack complexity, the privileges an attacker needs, whether user interaction is required, and the impact on confidentiality, integrity, and availability. The Base score is the number most teams rely on, and it is what NVD and most vendors publish.

Temporal or threat metrics. These reflect characteristics that change over time, such as whether working exploit code exists or whether a patch has been released. In CVSS v3.x, this group is called Temporal; in CVSS v4.0, it was reworked and renamed the Threat metric group. Either way, the intent is the same: adjust the score as the real-world situation around a vulnerability evolves.

Environmental metrics. These let an organization customize a score based on how important the affected asset is within its own infrastructure. A vulnerability on a mission-critical system can be scored higher for that organization than the published Base score suggests, and one on a low-value asset can be scored lower.

A quick note on versions, since teams encounter more than one in the wild. CVSS has evolved since its first release in 2005: v2 arrived in 2007, v3 in 2015, v3.1 in 2019, and v4.0 in 2022. Many vulnerability tools and threat intelligence feeds still report v3.1 scores, so security teams often work with v3.1 and v4.0 side by side. The core idea, a 0 to 10 severity score built from base, temporal, threat, and environmental metrics, holds across all of them.

Why a CVSS Score Is Not the Same as Risk

CVSS was designed to standardize severity, and it does that well. The problem is what teams ask it to do next: use it as the sole input for prioritization. A raw CVSS score cannot account for two factors that determine actual risk.

The first is the likelihood of exploitation. A Base score reflects how impactful a vulnerability would be if exploited, not whether anyone is exploiting it or realistically could. Two vulnerabilities can share a 9.8 while one has active, weaponized exploit code in the wild and the other has none.

The second is the business and environmental context. The same vulnerability carries a very different risk on an internet-facing server than on an air-gapped device that no attacker can reach. CVSS Base scores do not know where a device sits in your topology, what it connects to, or how much it matters to operations.

Left unaddressed, this gap produces a familiar problem: scanners return thousands of undifferentiated “Critical” and “High” findings, and teams have no principled way to decide which handful actually threaten the business. NVD itself is explicit on this point, stating that CVSS is a measure of severity, not risk.

Related: Vulnerability Prioritization from Asimily

How AI-Driven Attacks Widen the Gap

The distance between CVSS severity and real risk is growing as attackers adopt AI. Modern attackers use AI to identify, analyze, and exploit vulnerabilities faster than manual testing ever allowed, which erodes some of the assumptions built into a static severity score.

Consider attack complexity, one of the base metrics. A vulnerability historically rated “High Complexity” assumed an attacker needed deep expertise to build a working exploit. An AI-driven system can now analyze an application’s API surface, detect the flaw, and iterate through obfuscation techniques automatically, turning a high-complexity vulnerability into a low-complexity one in practice. The published score does not change, but the real barrier to exploitation has dropped.

The same speed shows up elsewhere. Attackers use AI to scan the CVE database and open-source commits for unpatched n-day vulnerabilities and to predict which legacy packages likely hide undiscovered flaws. They can ingest a vector string, correlate it against public research, and generate tailored exploit code before a human analyst has finished reviewing the patch ticket. Some of the most dangerous cases are low-scoring vulnerabilities that attackers chain together for lateral movement, exactly the findings a severity-only approach deprioritizes. Overly verbose error messages are a good example: individually minor, easily analyzed at scale, and useful as a foothold for further exploit development.

Related: The Role of AI in Risk Prioritization

Best Practices for Risk-Based Vulnerability Management

CVSS remains a useful foundation. The goal is not to discard it but to layer context on top of it, so prioritization reflects real risk rather than severity in isolation. Modern environments contain a diverse mix of Internet of Things (IoT), operational technology (OT), Internet of Medical Things (IoMT), and IT devices, and an effective approach has to account for all of them.

Continuously Discover and Inventory Assets

You cannot assess the risk on a device you do not know exists. A real-time, authoritative inventory across IoT, OT, IoMT, and IT is the foundation because an attacker only needs one unmanaged device with an exploitable vulnerability. When evaluating a solution, consider whether it:

• Discovers unmanaged and semi-managed IoT, OT, IoMT, and legacy devices safely and without disrupting operations, using agentless techniques
• Classifies devices automatically by capturing IP and MAC addresses, firmware versions, communication behavior, protocols, and external connections
• Provides real-time inventory updates without requiring manual scans or scheduled sweeps

Layer Context-Aware Exploitability Analysis on Top of CVSS Scores

Exploitability analysis evaluates each vulnerability against your actual network topology and device configuration, which is what tells you whether a CVSS 10.0 on an isolated device really outranks a CVSS 6.0 on a device with 10,000 network neighbors. When reviewing a solution, consider whether it:

• Runs exploit path analysis that simulates how an attacker could actually reach a device, accounting for network position and mitigating controls
• Uses device-level context to adjust risk scoring based on individual configuration, not just device type or CVE severity
• Identifies the vulnerabilities that carry the most genuine exploitability risk within your environment

Related: Smart Vulnerability Prioritization for Exposure Management

Map Exposure and Attack Paths Across Connected Devices

Attack path maps show how an attacker could reach a vulnerability and chain device connections to move across the environment. When reviewing a solution, consider whether it:

• Provides network-level visibility into device connectivity and communication patterns across all device types, not just traditional IT assets
• Identifies internet-facing or externally accessible devices that represent the highest-priority exposure surface
• Maps lateral movement risk to show which vulnerabilities open propagation paths into higher-value systems

Maintain a Unified Risk View Across IoT, OT, IoMT, and IT

A unified risk view correlates vulnerability and exposure data across the entire connected environment through a single prioritization engine, eliminating the silos that make consistent ranking impossible. When reviewing a solution, consider whether it:

• Normalizes risk across domains so findings on disparate device types can be compared and ranked together
• Consolidates data to remove manual correlation across separate scanning tools
• Reports consistently across all asset categories to support both operational triage and board-level risk communication

Automate Segmentation for Consistent Enforcement

Some devices cannot be patched: legacy hardware, OT equipment with uptime requirements, and devices mid-certification. For these, segmentation becomes a compensating control tied directly to compliance outcomes. To hold up, segmentation policies must be generated from real device behavior and enforced continuously. When reviewing a solution, consider whether it:

• Generates policy from observed device behavior and simulates the outcome against real traffic before any rule goes live
• Enforces policies across NAC platforms for consistent coverage
• Adapts policy continuously as devices, firmware, and network conditions change, with an audit trail that records what changed and why

Related: Segmentation Orchestration from Asimily

How Asimily Turns CVSS Severity Into Real Risk Prioritization

Every connected device that cannot run an agent, uses a proprietary protocol, or sits where a misconfigured policy carries operational consequences represents a coverage gap that traditional vulnerability tools were never built to close. Asimily’s Proactive Cyber Asset Defense Platform was built for that gap, across IoT, OT, IoMT, and IT.

Asimily provides a continuously updated, agentless, authoritative inventory of every IoT, OT, IoMT, and IT device, captured safely and without disruption, recording more than 100 parameters per device, including firmware version, communication behavior, installed services, and external connections. That gives security teams a foundation for vulnerability assessment that reflects the real environment rather than only what a scanner could reach.

Built on that visibility, ATT&CK Analysis is Asimily’s capability for determining exploitability. Rather than stopping at a generic CVSS score, it evaluates whether each vulnerability is actually exploitable on a specific device in a specific network topology, drawing on more than 15 threat intelligence sources including CISA KEV, the National Vulnerability Database, MITRE ATT&CK for ICS, ICS-CERT, and vendor SIRTs. The result is a reduction from millions of theoretical CVEs to roughly the 1% that carry real risk in the environment, which is where a team’s time should go. Risk Simulator then models the expected risk reduction of a proposed remediation before the team commits resources to it.

For devices where patching is not possible, Asimily’s Segmentation Orchestration generates conflict-free policies from observed device behavior through Policy Auto-Recommendation, previews their impact against real, observed traffic through Policy Simulation before any rule deploys, and enforces them across NAC infrastructure. Continuous Segmentation adapts policies as devices, firmware, and risk posture change, so enforcement never falls behind the network.

The outcome is a security posture where the highest-risk devices get immediate attention, compensating controls close the exposures that patching cannot reach, and the team can show measurable risk reduction instead of a longer list of findings.

See how Asimily prioritizes the 1% of devices driving the majority of your risk and request a demo today.