CVE vs CVSS: 4 key differences and how they work together

What are CVE and CVSS?

CVE (Common Vulnerabilities and Exposures) is a dictionary that catalogs and identifies unique software flaws, while CVSS (Common Vulnerability Scoring System) is a numerical scoring framework that rates the technical severity of those flaws. A CVE record contains basic information about the vulnerability, including a description and references to related resources. CVSS scores range from 0.0 to 10.0, with higher values representing greater technical severity. A CVSS score is not a complete measure of risk, because it can’t tell you whether the vulnerability can be exploited in your environment or what a compromise would cost your business.

Key differences:

• Purpose: CVE identifies and catalogs individual vulnerabilities, while CVSS measures their technical severity.
• Format: CVE uses unique identifiers such as CVE-2024-3094, while CVSS uses a score from 0.0 to 10.0 and a vector describing the scoring metrics.
• Maintained by: CVE records are coordinated by the CVE Program, operated by The MITRE Corporation, and published by CVE Numbering Authorities (CNAs), while the CVSS standard is managed by FIRST (Forum of Incident Response and Security Teams).
• Primary use: CVE is used to identify and correlate vulnerabilities across security sources, while CVSS helps assess severity and prioritize remediation.
• Examples: A CVE entry is a tracking label such as CVE-2021-44228 (Log4Shell), while a CVSS assessment is a score and vector, such as the 10.0 Critical rating that vulnerability received under CVSS v3.1.

How they work together:

• CVE provides the vulnerability identifier: Gives vendors, scanners, databases, and security teams a common reference for the same vulnerability.
• CVSS provides the severity score: Describes technical severity using a numerical score and vector based on exploitation and impact characteristics.
• Security tools map CVSS scores to CVEs: Vulnerability tools associate CVE findings with CVSS scores, vectors, versions, and other contextual data.
• One CVE can have different CVSS assessments: Scores may vary by assessment source, CVSS version, affected product, configuration, and scoring assumptions.

CVE vs CVSS: What is the difference?

CVE and CVSS are related standards, but they answer different questions. CVE answers “Which vulnerability is this?” by assigning a unique identifier. CVSS answers “How severe is this vulnerability?” by evaluating its technical characteristics and producing a severity score.

The two are often used together in vulnerability databases and security tools. A CVE record identifies the vulnerability, while an associated CVSS assessment helps teams understand its severity. However, not every CVE has a CVSS score, and CVSS can also be used to assess vulnerabilities outside the CVE system.

1. Purpose

The main purpose of CVE is to create a common naming system for publicly disclosed vulnerabilities. Without a standard identifier, vendors and security tools could describe the same vulnerability using different names. A CVE identifier gives security teams a reliable reference they can use to correlate alerts, advisories, patches, and threat intelligence.

CVSS has a different purpose, which is to provide a standardized method for describing the technical severity of a vulnerability. Its metrics consider factors such as how an attacker reaches the vulnerable component, whether privileges or user interaction are required, and what impact successful exploitation can have on confidentiality, integrity, and availability.

2. Format

CVE identifiers use a simple naming format, CVE-YYYY-NNNN, where the year is followed by a sequence number of four or more digits. For example, CVE-2024-3094 identifies one specific vulnerability, the XZ Utils backdoor, and nothing else. The CVE identifier itself contains no information about severity, affected systems, exploitability, or business risk, so those details have to come from the CVE record and related sources.

CVSS uses a score from 0.0 to 10.0 and a vector string that records the metric values behind the score. For example, CVSS v3.1 uses metrics such as attack vector, attack complexity, privileges required, user interaction, scope, and impact. The vector makes the assessment reproducible because analysts can see which values were selected to produce the score.

3. Maintained by

The CVE Program is sponsored by the U.S. Cybersecurity and Infrastructure Security Agency (CISA) and operated by The MITRE Corporation. The program works with CVE Numbering Authorities (CNAs), which include software vendors, security organizations, and other authorized entities. CNAs reserve CVE identifiers and publish records for vulnerabilities within their assigned scope.

CVSS is maintained by the Forum of Incident Response and Security Teams (FIRST). FIRST develops and publishes the CVSS specification, including metric definitions and scoring formulas. The standard has evolved through several versions, so security teams should check which CVSS version was used when interpreting or comparing scores.

4. Primary use

CVE is mainly used for vulnerability identification and correlation. Vulnerability scanners can report CVE identifiers detected on a system, vendors can reference them in security advisories, and patch management platforms can associate updates with the vulnerabilities they address. This common identifier makes it easier to combine information from multiple security sources.

CVSS is mainly used for severity assessment and vulnerability prioritization. Organizations can use CVSS scores to help sort large numbers of findings and identify technically severe issues. However, CVSS should not be treated as a complete measure of risk. Whether the vulnerability can be exploited in your environment, internet exposure, active exploitation, compensating controls, and business impact can all change remediation priorities.

Examples

CVE-2024-3094 is an example of a CVE identifier. It refers specifically to the backdoor discovered in certain versions of XZ Utils. Security advisories, vulnerability databases, scanners, and operating system vendors can all use this identifier when discussing the same vulnerability, which removes any doubt about which issue they mean.

A CVSS assessment might assign a vulnerability a base score of 9.8 under CVSS v3.1, placing it in the Critical severity range for that version. The score can be accompanied by a vector showing why it received that value. The CVE identifier tells administrators which vulnerability they are dealing with, while the CVSS assessment provides structured information about its technical severity.

How CVE and CVSS work together

CVE provides the vulnerability identifier

A CVE identifier provides a unique reference for a publicly disclosed vulnerability. For example, CVE-2021-44228 lets vendors, vulnerability databases, scanners, and security teams refer to the Log4Shell vulnerability in Apache Log4j without relying on product-specific vulnerability names.

The identifier does not describe how dangerous the vulnerability is. It acts primarily as a key that connects information from different sources. A security team can use a CVE identifier to find:

• Vendor advisories
• Affected versions
• Patches
• Exploit information
• Severity assessments related to the vulnerability

This common reference is especially useful when organizations use several security products. If a vulnerability scanner and a patch management system both reference the same CVE, teams can connect a detected vulnerability to the update intended to remediate it.

CVSS provides the severity score

CVSS adds severity information to a vulnerability assessment. Depending on the CVSS version, its metrics describe characteristics such as:

• The attack vector
• Attack complexity
• Privileges required
• User interaction
• The security impact of successful exploitation

These values are represented through a CVSS vector and used to calculate a numerical score from 0.0 to 10.0. The vector is important because two vulnerabilities with similar scores can have different exploitation requirements and impacts.

CVSS measures technical severity rather than providing a complete risk calculation for an organization. Teams commonly combine the score with contextual information such as whether the vulnerable system is exposed to the internet, whether an exploit is available, and how important the affected asset is.

How security tools map CVSS scores to CVEs

Vulnerability management tools commonly use CVE identifiers as keys for correlating vulnerability information. After identifying an affected product or software version, a scanner can associate the finding with a CVE and retrieve related severity data from:

• Vendor advisories
• Vulnerability databases
• Other data feeds

The tool can then display a CVSS score alongside the CVE identifier. Some products also store the complete CVSS vector and version so users can determine which metrics produced the score. This matters because comparing scores without knowing whether they use CVSS v3.1, CVSS v4.0, or another version can be misleading.

Tools may enrich the CVE and CVSS information with additional data. Examples include known exploitation, available patches, affected assets, network exposure, and threat intelligence. These inputs help vulnerability management platforms move from general technical severity toward prioritization based on an organization’s environment.

Why one CVE can have different CVSS assessments

A single CVE can have multiple CVSS assessments because different organizations may evaluate the vulnerability independently. A software vendor, vulnerability database, and security research organization can select different metric values based on their interpretation of exploitation requirements or impact.

Scores can also differ because assessments use different CVSS versions. CVSS v3.1 and CVSS v4.0 use different metrics and scoring models, so their numerical results should not be treated as directly interchangeable without considering the version and vector.

Product and deployment differences can create additional variation. The same vulnerability may affect several products or configurations, and its impact may not be identical in every case. When scores differ, rather than relying only on the numerical value, security teams should examine:

• The score source
• The CVSS version
• The vector
• The affected product
• Assessment assumptions

How to read a CVE and its CVSS score

When reviewing a vulnerability:

1. Start with its CVE identifier, such as CVE-2021-44228, which provides a unique reference you can use to find the corresponding record in vulnerability databases, vendor advisories, and security tools. The CVE record typically describes the affected product, vulnerability type, affected versions, and references for further technical information.
2. Next, check the associated CVSS score and its version. CVSS uses a scale from 0.0 to 10.0, where a higher score represents greater technical severity. The score is commonly accompanied by a severity category such as Low, Medium, High, or Critical. Because CVSS versions use different scoring models, the version should always be considered when interpreting a score.
3. Read the CVSS vector, which provides more detail than the numerical score alone. It shows the individual metrics used in the assessment, such as whether exploitation requires network access, elevated privileges, specific attack conditions, or user interaction. It also describes the potential effects on confidentiality, integrity, and availability.
4. Add operational context before making remediation decisions. Check which assets are affected, whether the vulnerable code is running and exposed, whether a patch or mitigation is available, and whether there is reliable evidence of exploitation. This gives a far more useful picture of actual risk than either the CVE identifier or the CVSS score alone.

For example, a CVE with a high CVSS score and a network-based attack vector may deserve close attention because exploitation could potentially occur remotely. However, the CVSS score does not show whether the vulnerable component exists in a particular environment, whether its configuration allows the attack, or whether attackers are actively exploiting the issue.

Related content: Read our guide to CVE remediation

Why CVSS alone is not enough for vulnerability prioritization

Severity does not equal exploitability

A high CVSS score does not mean a vulnerability can be exploited in your environment. The base score describes the vulnerability in general, assuming the affected component is present and reachable. Whether it can actually be exploited depends on conditions the score can’t see, such as whether the vulnerable code is loaded and running, whether the vulnerable function can be reached, how the system is configured, and which controls sit in front of it.

The opposite also happens, because a medium-severity vulnerability on an exposed service with no compensating controls can be easier to exploit in your environment than a critical one buried in a package that never runs. Checking those conditions has traditionally meant a security engineer investigating each finding by hand, which is why most teams fall back on the score. AI-native vulnerability management platforms now take on that investigation for every finding, so teams can prioritize by whether a vulnerability can be exploited rather than by how severe it looks on paper.

CVSS does not fully reflect business context

CVSS describes technical characteristics of a vulnerability, not the complete consequences for a particular organization. The same vulnerability could affect an internal test server and a production system processing sensitive customer information, while retaining the same base severity score.

Business context can include the sensitivity of stored data, regulatory requirements, service availability requirements, and the operational consequences of compromise. Adding this information helps teams distinguish technically severe vulnerabilities from those that create significant business risk.

Asset criticality changes remediation priority

The importance of the affected asset can change remediation priority considerably. A vulnerability on an internet-facing identity system, payment service, or production database may require faster action than the same vulnerability on an isolated, low-value development system.

Asset inventories and classification systems can provide this context. Security teams can combine CVSS data with information about system ownership, data sensitivity, network location, business function, and dependencies to determine which vulnerable assets require attention first.

Public exploitation can change risk

Risk increases when attackers are actively exploiting a vulnerability or when working exploit code becomes publicly available. These developments reduce the knowledge and effort needed to conduct attacks, which can make exploitation practical for a wider range of threat actors.

Security teams should monitor sources such as vendor advisories, threat intelligence, exploit repositories, and CISA’s Known Exploited Vulnerabilities catalog. Evidence of active exploitation can justify accelerating remediation even when the vulnerability does not have one of the highest CVSS scores.

Compensating controls can reduce exposure

Security controls can reduce the practical exposure created by a vulnerability even when they do not remove the underlying flaw. Examples include network segmentation, firewalls, access controls, application allowlisting, disabling vulnerable functionality, and restricting a service to trusted systems.

These controls should not automatically be treated as substitutes for patching. Teams need to verify that a control actually blocks or limits the relevant attack path and monitor it for changes. When immediate patching is not possible, validated compensating controls can help reduce exposure until permanent remediation is completed.

Prioritizing exploitable CVEs beyond CVSS with Maze

While working with security teams, Maze’s founders kept running into the same problem. Teams were sorting CVEs by CVSS score because their tools couldn’t gather the context needed to tell which vulnerabilities could actually be exploited in their environment, so engineers spent much of their time patching findings that were never a real risk. They built Maze so that every vulnerability gets the investigation those teams never had the time to run.

Given unlimited time, a security engineer would take each CVE, work out what has to be true for it to be exploited, and then check your code, your build, and your cloud to see whether those conditions exist. Maze’s AI was built to think the same way. It decides what context each finding needs, gathers it for itself, and reasons over configuration, controls, exposure, and runtime state to decide whether the vulnerability can be exploited in your specific environment, with the evidence behind every verdict. CVSS and EPSS become inputs to that investigation instead of the final answer.

Maze uses AI to find the vulnerabilities in your code and its dependencies, and Maze Cloud investigates the vulnerabilities your existing scanners find in the workloads running in your cloud, from known CVEs to zero-days. For the ones that are exploitable, Maze traces the root cause, writes a fix that matches your code, and gets it to the developer who owns it.

Key capabilities of Maze:

• Investigate every vulnerability in your backlog: Maze investigates every finding your scanners report, across cloud and code, instead of a sample or only the criticals, so the thousands of vulnerabilities sitting in your backlog each get a verdict with evidence rather than waiting for someone to have time.
• Exploitability investigation: Maze’s AI researches what each vulnerability needs in order to be exploited and checks whether those conditions exist in your environment. Vulnerabilities that aren’t exploitable are closed with the full reasoning behind the decision. On average, Maze finds that over 70% of vulnerabilities are not exploitable.
• AI-SAST: AI-SAST runs on every pull request and across your entire codebase, finding flaws in the code your team writes, including business-logic issues such as authentication and authorization gaps that never receive a CVE.
• AI-SCA: Many of the CVEs teams track live in open source dependencies. AI-SCA uses AI to trace the path from an entry point to the vulnerable function, however many hops deep, then checks whether an attacker can control what reaches it and whether that code is running in your cloud. If you already run something like Dependabot, Maze investigates and deduplicates those findings too.
• One CVE, one ticket: Maze gathers context from your code and cloud and shares it across every investigation, so a vulnerable library is assessed together with where it runs, and the same CVE reported by several tools becomes one ticket with one fix.
• Severity based on your environment: Maze scores each exploitable vulnerability on how likely it is to be exploited and how much harm it would do to your business, so a critical CVE in a staging service that never sees real traffic doesn’t outrank a medium one in your payment flow.
• Zero-day sweeps: When a new vulnerability is disclosed, Maze picks it up in near real time and checks every affected instance across code and cloud, so teams know whether they’re affected before scanners have a signature for it.
• Fixes where your developers work: Maze writes a fix that matches your code and environment and routes it to the owner through your ticketing platform or as a pull request. Fixes can also go to the coding agent your team already uses, such as Claude Code or Cursor, and when no patch exists, Maze recommends a mitigation that makes the vulnerability not exploitable.

See how Maze investigates cloud and code vulnerabilities and turns CVE and CVSS data into a focused list of the vulnerabilities that can actually be exploited.