CVE and CVSS

CVE uniquely names known vulnerabilities, while CVSS rates their severity on a scale from 0 to 10. This article explains how the two systems work together, which metrics lie behind the score and why the CVSS value alone does not yet determine patch priority.

Every week, new security vulnerabilities become public, far more than a company can close in a timely manner. So that everyone involved can talk about the same problems, there are two standards: CVE names vulnerabilities uniquely, and CVSS makes their severity comparable. Anyone who classifies both correctly prioritizes better and ties up fewer resources in the wrong places.

What are CVE and CVSS?

CVE stands for Common Vulnerabilities and Exposures and is a public catalog of specific, disclosed vulnerabilities. Each vulnerability receives a unique identifier following the pattern CVE-year-number, for example CVE-2024-12345. The entries are assigned by authorized bodies known as CNAs, coordinated by the US organization MITRE. An entry describes which product is affected in which versions and references further information from the manufacturer. This makes it unambiguous what is being referred to when an advisory, a scanner or a service provider cites an identifier.

CVSS stands for Common Vulnerability Scoring System and quantifies how serious a vulnerability is. The standard is maintained by the international consortium FIRST. The result is a value between 0.0 and 10.0, supplemented for orientation by the levels low, medium, high and critical. In short: CVE identifies a vulnerability, and CVSS rates it.

How does scoring with CVSS work?

The CVSS value is composed of several metric groups:

Base metrics: They describe the permanent properties of a vulnerability: is it exploitable over the network or only locally? Does the attacker need privileges or an action by the user? How severely do confidentiality, integrity and availability suffer? From this comes the base score that manufacturers and databases publish.
Temporal metrics: They reflect the development over time, such as whether exploit code is publicly available and whether the manufacturer already provides a patch. In the current version, CVSS 4.0, this group is called threat metrics.
Environmental metrics: They adapt the assessment to your own company: how important is the affected system, and which protective measures already exist? Only this adaptation turns the generic value into a company-specific statement.
Vector string: The assessment is documented as a compact character string. This keeps it traceable how a value came about, and teams can recalculate it for their own environment.

In practice, the base score is usually the one cited. This is exactly where the trap lies: a vulnerability with a value of 9.8 on an isolated test system can be more harmless than a 7.5 on an internet-facing server with customer data. Reachability, exposure, business criticality and active exploitation all play a part. Good vulnerability management therefore combines the CVSS value with context, for example with indications of active exploitation and with reachability analyses from your own network.

Why it matters

They create a common language between manufacturers, scanners, service providers and authorities, without which a coordinated response would hardly be possible.
Advisories, scanner findings and patches can be clearly matched to one another.
CVSS provides a first, comparable estimate of how dangerous a vulnerability is in principle.
Patch policies and contracts can refer to defined thresholds, for example deadlines for critical vulnerabilities.
Reports to management and auditors become traceable because they are based on an open standard.

Typical scenarios

A manufacturer publishes an advisory with a CVE identifier, and the team checks via the inventory which systems use the affected version.
After its weekly run, the vulnerability scanner reports hundreds of findings, and the team has to decide which to address first.
A vulnerability with a medium score is being actively exploited and therefore moves ahead of formally critical but practically hard-to-reach findings.
No patch yet exists for a vulnerability, and until then interim measures such as stricter network rules provide protection. If it is a previously unknown vulnerability, it is called a zero-day .
The environmental metrics downgrade a vulnerability on a strictly isolated legacy system, documented and with justification.

CVE vs. CWE

CVE refers to a specific vulnerability in a specific product, including the affected versions. CWE (Common Weakness Enumeration), by contrast, catalogs abstract classes of weaknesses, such as SQL injection or buffer overflows. A CWE class thus stands behind many individual CVE entries. For operations, CVE is what counts: which systems need which patch? For development and procurement, CWE is more interesting: which classes of weakness recur in your own or purchased products, and how can they be avoided in the future?

Prioritizing and mitigating vulnerabilities at KAEMI

A score does not replace a decision. KAEMI helps companies turn assessments into effective measures. A central lever is reachability: with Zero Trust microsegmentation , the number of systems that can reach a vulnerable component at all decreases. This mitigates many findings before a patch is applied, and it demonstrably improves the rating in the environmental metrics. For exposed applications, Application Security adds protective mechanisms that intercept known attack patterns while the patch window is still open. If you would like to put your prioritization on a solid footing, contact us via our contact form .

Frequently asked questions about CVE and CVSS

Who assigns CVE identifiers, and how is an entry created?

CVE identifiers are assigned by authorized bodies, the CVE Numbering Authorities. These include large software manufacturers for their own products as well as coordination bodies from the CERT environment, and the overall system is coordinated by the US organization MITRE. When a researcher or manufacturer reports a vulnerability, the responsible body reserves an identifier and publishes the entry once the details have been agreed.

From what CVSS value is a vulnerability considered critical?

According to the common classification, values from 9.0 count as critical, between 7.0 and 8.9 as high, between 4.0 and 6.9 as medium and below that as low. These levels refer to the base score. For your own prioritization, the value should always be combined with context: a high score on an unreachable system is rarely the most urgent case.

Is it enough to fix only critical vulnerabilities?

No. Attackers frequently chain several medium vulnerabilities into a complete attack path, and actively exploited vulnerabilities often have no critical base score at all. It makes sense to prioritize by active exploitation and reachability, weighted by the business importance of the system. Critical findings on exposed systems come first, after which the approach follows risk consistently rather than rigidly following the score.

What distinguishes CVE from CWE?

CVE names a specific vulnerability in a particular product and particular versions. CWE describes abstract classes of weaknesses such as missing input validation, independent of the product. An example: behind many individual CVE entries for web applications lies the same CWE class, SQL injection. Operations teams work with CVE for patching, while development teams use CWE to systematically avoid classes of weakness in their own code.

What can you do if no patch yet exists for a vulnerability?

Until the manufacturer delivers, interim measures count: restrict the reachability of the system, for example through network segmentation or firewall rules, disable affected functions, authenticate access more strongly and monitor the system closely. For actively exploited vulnerabilities without a patch, known as zero-days, temporarily disconnecting from the network can also be the most economical decision. After the patch, the measures are rolled back in an orderly fashion.