CWE vs CVE vs CVSS Explained: Differences & Limits

If you work in application security and vulnerability management, it takes only a few minutes before you run into a whole alphabet soup of acronyms: CWE, CVE, CVSS, EPSS. In ticketing systems and in the reports of common CVE scanners, these terms are often used interchangeably.

Yet they describe completely different things – more precisely, different stages in the lifecycle of a security vulnerability. Once you understand the difference, it quickly becomes clear why classic prioritization based purely on numeric scores is reaching its limits today.

1. CWE: What kind of flaw is in the code?

Everything starts in the source code. Every security vulnerability has a technical root cause – a design or programming error. This is exactly where CWE (Common Weakness Enumeration) comes in.

CWE is a community-maintained catalog of weakness types in software and hardware. It does not describe a specific bug in a particular product, but the abstract category of the flaw.

Each of these categories is primarily defined by a particular attack vector. An attack vector describes the path and method an attacker can use to exploit a vulnerability – for example, whether they inject manipulated input through a web form, overflow memory regions or exploit missing authorization checks in an API.

Typical examples of CWEs are:

• CWE-89 (SQL Injection): User input is passed to a database query without validation.
• CWE-79 (Cross-Site Scripting / XSS): Attackers can inject foreign script code into a trusted web page.
• CWE-787 (Out-of-bounds Write): The program writes data past the end of the intended memory buffer.

In short: CWE names the disease (e.g. “SQL injection”), but not yet the specific patient.

Static code analysis (SAST) tools search your own code for exactly these CWE patterns.

2. CVE: From discovery to an official identifier

So what happens when a security researcher or developer discovers a concrete vulnerability (in other words, a CWE) in a widely used open-source library or a piece of commercial software?

Usually, a coordinated reporting process kicks off (Coordinated Vulnerability Disclosure):

1. Report to the vendor: The finder reports the vulnerability confidentially to the vendor or to the project's maintainers.
2. Vendor advisories: Many projects publish initial warnings and patches directly through their own channels – in open source often as a GitHub Security Advisory (GHSA), or through vendors' security bulletins.
3. Assigning the CVE ID: So that every security tool worldwide talks about exactly the same vulnerability, a unique identifier is needed: the CVE ID (Common Vulnerabilities and Exposures).

This system is managed by the MITRE Corporation together with so-called CVE Numbering Authorities (CNAs). Large tech companies, open-source foundations (such as GitHub or the Apache Foundation) and national security agencies act as CNAs themselves and may assign their own CVE IDs following the scheme CVE-YEAR-NNNNN (e.g. CVE-2026-12345).

So while CWE describes the general flaw pattern, a CVE is the concrete fingerprint of a single issue in a specific software version.

3. CVSS: How dangerous is the vulnerability?

Once hundreds of CVEs are known, organizations face a practical problem: which vulnerability do we fix first? CVSS (Common Vulnerability Scoring System) was created to answer that question. It translates the technical characteristics of a vulnerability into a numeric score from 0.0 to 10.0.

How is a CVSS vector calculated?

A CVSS score doesn't come out of thin air – it is calculated from a so-called vector string. This string combines several metrics (the base metrics):

• Attack Vector (AV): Does the attacker need physical access to the device, do they have to be on the same local network, or is the open internet enough (AV:N for Network)?
• Attack Complexity (AC): How much effort does the attack take? Does it require special preconditions (AC:H), or does it work at the push of a button (AC:L)?
• Privileges Required (PR) & User Interaction (UI): Does the attacker need admin rights up front, or does a user first have to click a crafted link?
• Impact: How severely are confidentiality, integrity and availability affected?

For a long time, CVSS v3.1 was the undisputed standard. CVSS v4.0 has since been introduced, which among other things allows finer granularity for system requirements and for the impact on downstream systems (Subsequent Systems).

The problem with CVSS (and why EPSS doesn't solve everything either)

In theory, the system sounds like a perfect sorting machine for vulnerability management. In practice, however, blind trust in the CVSS score has turned into a real problem:

1. Score inflation: Because the base score always assumes the “worst case”, a huge share of all new CVEs ends up rated High (7.0–8.9) or Critical (9.0–10.0). When your backlog suddenly holds 400 “critical” tickets, the rating loses its power to steer your work.
2. Scoring backlog (NVD backlog): For a long time, the US National Vulnerability Database (NVD) analyzed almost every new CVE promptly and assigned it an independent CVSS score. Since 2024, the NVD has barely been able to keep up with the sheer flood of new reports. Thousands of recent CVEs go weeks or months without an official NVD assessment, or the scores assigned by vendors and databases contradict each other massively.
3. No connection to reality: A CVSS score of 9.8 only means that a vulnerability would theoretically be easy to exploit with severe damage – not that a working exploit for it even exists.

The stopgap: EPSS and KEV

To close this gap, EPSS (Exploit Prediction Scoring System) was created. Instead of measuring theoretical damage, EPSS uses historical data and machine learning to calculate a probability (between 0 and 100 %) that a vulnerability will actually be exploited “in the wild” within the next 30 days. This is often complemented by the KEV (Known Exploited Vulnerabilities) catalog from the US agency CISA, which lists vulnerabilities that attackers are already actively exploiting.

But EPSS has a blind spot too: it looks at the world globally. A vulnerability with a low EPSS score can still be extremely dangerous for your organization if it sits right in your publicly reachable authentication logic. Conversely, a CVE with high CVSS and EPSS scores is completely harmless to you if the affected function of the library is never called in your code.

The alternative: application context, data-flow analysis and AI

Precisely because global scores like CVSS and EPSS know nothing about your own software architecture, application security is undergoing a shift in thinking. Instead of continuing to flood security teams with theoretical risk scores, the concrete application context is moving to the center.

Modern approaches combine three layers for this:

1. Reachability analysis: Instead of merely using a dependency scanner to check whether a vulnerable library appears in the SBOM, it checks whether the vulnerable code path is actually called by your own application.
2. Data-flow & taint analysis: Even if a vulnerable function is reachable in the code, an attacker still has to be able to get controlled data there. Taint analysis traces the flow of data through the application: does external user input (e.g. from an HTTP request) actually reach the vulnerable spot unfiltered and without prior validation (sanitization)?
3. AI-assisted context assessment: To quickly make sense of complex frameworks, custom security controls and architectural decisions, the targeted use of AI models helps today. They support the analysis of the real code context around a finding and automatically filter out false positives.

From theoretical scores to real relevance – with Farion

This is exactly the approach we take with Farion. Instead of leaving development teams alone with long lists of CVEs and theoretical CVSS scores, Farion consolidates the results of your scanners and matches them directly against your application context.

By combining dependency analysis, reachability analysis, automated data-flow analysis and AI-assisted evaluation, Farion reliably determines whether a reported CVE is actually exploitable in your specific architecture. This drastically reduces the noise in your backlog and lets you focus your development time precisely on the vulnerabilities that pose a real risk to your organization.