If you spend any time inside a vulnerability scanner, a finding queue, or a remediation ticket, you meet three short codes over and over. One looks like CVE-2021-44228. Another looks like CWE-79. The third looks less like an identifier and more like a recipe, something along the lines of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H with a number attached. New analysts often treat all three as interchangeable severity tags. They are not. Each answers a different question, each is maintained by a different authority, and each does a specific job in your triage process.
This article is a practitioner walk-through of what CVE, CWE and CVSS actually represent, how they differ, and how they read together when you look at a single vulnerability. We will not stop at definitions. We will show how these three identifiers sit side by side on a vulnerability template in PMAP, why a template library stores all three at once, and how they move from raw codes into an actual remediation decision. If you can read these three fields fluently, you can read almost any scanner output, advisory, or finding record that crosses your desk.
The short version, before we go deep. CVE names a specific vulnerability. CWE classifies the underlying weakness behind it. CVSS scores how severe it is. Identity, class, severity. Keep that triplet in mind and the rest of this article fills in the detail.
Three Identifiers, Three Different Jobs
The fastest way to stop confusing CVE, CWE and CVSS is to stop thinking of them as three flavors of the same thing. They live at different levels of abstraction, and they are useful precisely because they do not overlap.
CVE is an identity. It points at one concrete, publicly disclosed vulnerability in one product or library. When you say CVE-2021-44228, every security team on the planet knows you mean the Log4Shell remote code execution flaw in Apache Log4j. The identifier is a shared name so that vendors, scanners, advisories and analysts all talk about the same issue without ambiguity.
CWE is a class. It does not point at a single flaw. It points at the kind of mistake that produced the flaw. CWE-79 is “Improper Neutralization of Input During Web Page Generation”, which most people know as cross-site scripting. Thousands of separate CVEs share that same root weakness. CWE lets you group, count and reason about patterns rather than individual incidents.
CVSS is a grade. It is not a name and it is not a class. It is a structured way of describing how exploitable and how impactful a vulnerability is, expressed as a vector string and condensed into a numeric score. Two completely unrelated CVEs can share an identical CVSS score because severity is independent of identity.
So a single finding might read: this is CVE-2021-44228 (which specific flaw), it belongs to a weakness class around deserialization and injection (what kind of mistake), and it scores 10.0 on the CVSS scale (how bad it is). Three answers, three jobs, one finding.
In PMAP, this separation is not just a mental model. It is how the data is stored. A vulnerability template carries CVE identifiers, CWE identifiers and CVSS scoring as distinct fields rather than collapsing them into one severity tag. A template is a reusable, scanner-agnostic definition of a known vulnerability class, and it holds all three groups together so that when the template matches an incoming finding, the finding inherits every dimension at once. The rest of this article walks each identifier in turn, then shows how they read together on that template.
CVE, the Identity of a Known Vulnerability
CVE stands for Common Vulnerabilities and Exposures. It is a public catalog, run as the CVE Program under MITRE, that assigns a unique identifier to each publicly known security vulnerability. The format is simple. You see CVE, then the year the identifier was reserved, then a sequence number, like CVE-2024-3094. The year is the assignment year, not necessarily the year the vulnerability was introduced or discovered, which trips up a lot of newcomers.
The point of CVE is coordination. Before the program existed, one vendor might call a flaw “the SSL renegotiation bug” while a scanner called it “plugin 42873” and an advisory called it something else entirely. Cross-referencing was painful and error-prone. A CVE identifier solves that. It is a stable, globally agreed name. When a Tenable plugin, a Qualys QID and a vendor advisory all reference CVE-2024-3094, you know with certainty they are describing the same underlying issue, even though each tool uses its own internal numbering.
A few properties matter in day-to-day work.
A CVE describes a specific vulnerability, usually in a specific product or version range. It is concrete. You can typically point at the affected software and the conditions under which it is vulnerable.
A CVE is an identity, not a severity. The identifier itself tells you nothing about how dangerous the flaw is. That is what CVSS is for. Plenty of low-impact issues have CVEs, and so do the most catastrophic ones. The identifier is neutral.
A CVE can map to detailed analysis elsewhere. The National Vulnerability Database, run by NIST, enriches CVE records with CVSS scores, affected-product data and CWE mappings. So while MITRE owns the CVE identifier, NVD is usually where you go to read the structured severity and weakness metadata attached to it. The two systems work together. MITRE assigns the name, NVD analyses and enriches it.
In PMAP, CVE identifiers live on a vulnerability template inside a cve_ids[] array. Storing them as an array, not a single value, is deliberate. A single template, representing one vulnerability class as your content team defines it, can be associated with more than one CVE when several disclosed flaws share the same remediation and the same context. Because the field is an array, the platform can run exact-match lookups across the whole library. When a scanner result arrives carrying a CVE identifier, PMAP can check that CVE against every template’s cve_ids[] and find an exact overlap. That overlap is the strongest, most deterministic signal the matching engine has, which is why CVE exact-match sits at the very top of the Smart Match priority order with the highest possible confidence. We will come back to that pipeline later. For now the key idea is that CVE is the identity, and identity is what makes precise, exact lookups possible.
CWE, the Class of Weakness Behind It
CWE stands for Common Weakness Enumeration. It is also maintained by MITRE, and at first glance it looks similar to CVE, just another XXX-number code. The difference is fundamental. CVE points at an instance. CWE points at a category.
Think of it through an analogy. If CVE is “the specific car that crashed at this intersection on this date”, CWE is “the design flaw in the brake system that makes this whole model prone to crashing”. One is an event. The other is the underlying cause shared by many events.
CWE-79 is cross-site scripting. CWE-89 is SQL injection. CWE-787 is out-of-bounds write. CWE-22 is path traversal. Each names a recurring category of software weakness. Any number of distinct CVEs can roll up to the same CWE, because the same class of mistake gets made again and again across different products and codebases.
Why does this matter to a practitioner? Because patterns drive better decisions than incidents do.
CWE lets you see systemic problems. If you map your findings to CWE and notice that a large share of your open vulnerabilities cluster under CWE-79 and CWE-89, that is not nine hundred unrelated tickets. That is one story. Your input validation and output encoding practices need work. CVE-by-CVE you would never see the pattern. By weakness class it is obvious.
CWE supports root-cause thinking. When you remediate a single CVE you fix one instance. When you understand the CWE, you can ask whether the same weakness exists elsewhere in your estate, untested and undisclosed. The weakness class points you toward prevention, not just patching.
CWE connects to broader prioritization work. The CWE Top 25 Most Dangerous Software Weaknesses, published by MITRE, ranks the weakness classes most commonly exploited and most impactful. Knowing which CWE a finding belongs to lets you check it against that kind of industry signal.
In PMAP, CWE identifiers live on the template in a cwe_ids[] array, sitting right alongside the cve_ids[] array. The structure mirrors CVE storage for a reason. Both are identifier arrays, both support exact-match filtering, and both let a single template carry several values. You can filter the template library by a CWE identifier to pull every template tied to a given weakness class, which is exactly the kind of pattern query that makes CWE valuable. The template links the specific identities (CVEs) to the broader class (CWE) in one record, so when the template matches an incoming finding, the finding gains both the precise name and the weakness category in a single step. That is enrichment doing real work. An analyst no longer has to look up “what kind of weakness is this” by hand, because the template already carries the class.
CVSS, the Severity Grade
CVSS stands for Common Vulnerability Scoring System. Unlike CVE and CWE, it is not maintained by MITRE. It is maintained by FIRST, the Forum of Incident Response and Security Teams, which publishes the specification and the scoring rules. And unlike the other two, CVSS is not an identifier at all. It is a measurement framework. Its job is to answer one question. How severe is this vulnerability, expressed in a way that is consistent and comparable across every flaw you face.
CVSS produces two things you will see constantly. A numeric score between 0.0 and 10.0, and a vector string that explains how that score was reached. Both matter, and they are stored separately in PMAP, which we will get to.
The numeric score is the headline. Under the widely used CVSS v3.1 standard from FIRST, scores map to qualitative severity bands as follows. A score of 0.0 is None. From 0.1 to 3.9 is Low. From 4.0 to 6.9 is Medium. From 7.0 to 8.9 is High. From 9.0 to 10.0 is Critical. These bands are defined by FIRST in the CVSS specification, not invented per vendor, so a 9.8 means the same level of theoretical severity whether it came from NVD, a scanner, or your own analysts. CVSS v4.0 has since been published by FIRST and refines the model further, but the band structure and the goal stay the same. Make severity comparable.
That comparability is the entire value proposition. Without a shared scoring system, “high severity” would mean whatever each tool’s vendor decided, and you could not stack findings from different scanners into one prioritized queue. CVSS gives you a common ruler.
Reading a CVSS Vector
The number is convenient but lossy. Two findings can both score 7.5 for very different reasons, and the reasons change how you respond. That is why CVSS also produces a vector string, which is the structured breakdown behind the score. Learning to read it is one of the highest-leverage skills a triage analyst can pick up.
A CVSS v3.1 base vector looks like this:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HEach segment is a metric and its value. The base metrics break into two groups, exploitability and impact.
The exploitability metrics describe how hard the flaw is to attack. AV is Attack Vector, where N means Network (reachable remotely, the worst case), down through Adjacent, Local and Physical. AC is Attack Complexity, where L is Low (easy, no special conditions). PR is Privileges Required, where N means none are needed. UI is User Interaction, where N means the attack needs no victim action. S is Scope, where U means Unchanged and C means the exploit can reach beyond the vulnerable component.
The impact metrics describe what an attacker gains. C, I and A are Confidentiality, Integrity and Availability, each rated None, Low or High. In the example above all three read H, which means a successful exploit fully compromises all three.
Read end to end, that vector says: attackable over the network, low complexity, no privileges or user interaction required, with full impact to confidentiality, integrity and availability. That is the profile of a critical, trivially exploitable, remotely reachable flaw, and the score of 9.8 follows from it. Now compare that to a 9.8 with AV:L and PR:H, meaning local access and high privileges required. Same number, very different real-world exposure. The analyst who reads the vector treats those two findings differently. The analyst who reads only the number treats them the same and gets prioritization wrong.
In PMAP, the vector is preserved, not discarded. A vulnerability template stores cvss_vector as a string field, sitting right next to the cvss_score float field. Both are kept. The score gives you the fast sort, and the vector gives you the context to defend a decision. Because the template carries both, every finding the template matches inherits both. An analyst can pull up a matched finding and read the exploitability profile straight from the inherited vector rather than hunting for it in an external database.
Score Versus Severity Label
Here is a distinction that catches even experienced practitioners. The CVSS score and the severity label your platform displays are not always the same thing, and PMAP keeps them as separate fields on purpose.
The cvss_score is the numeric output of the CVSS calculation, the 9.8 or the 5.4. It is a float, and it reflects the formal scoring of the vulnerability class as your content team recorded it.
The severity field is a separate classification on the template. It is not a copy of the CVSS band. Storing severity independently from the CVSS score is deliberate. The raw CVSS base score reflects theoretical severity under standard assumptions, but your organization may classify a finding’s operational severity differently once you account for context the base score does not see. A flaw might score Critical on the CVSS scale, yet if the affected system is isolated and compensating controls are in place, your team may track its working severity at a different level. Conversely, a Medium base score on an internet-facing crown-jewel asset may warrant elevated handling.
Because PMAP stores cvss_score and severity as distinct fields, the platform never forces you to overwrite the objective CVSS number with your subjective operational judgment, or vice versa. You keep the standardized grade for comparability and audit, and you keep an organizational severity for routing and prioritization. They inform each other without erasing each other. This is also why the template library lets you filter by severity as its own facet. You are filtering on the classification you assigned, with the CVSS score available right beside it for reference.
How the Three Read Together on a Template
Definitions in isolation only get you so far. The real skill is reading all three at once on a single record, and that is exactly what a PMAP vulnerability template puts in front of you. The template groups its fields by concern, and the identifiers live together in one Identifiers group. That group holds, side by side: the cve_ids[] array, the cwe_ids[] array, the cvss_vector string, the cvss_score float, a references[] array of source links, and the mitre_technique_ids[] array that maps the class to MITRE ATT&CK techniques.
Putting them in one group is not cosmetic. It reflects how an analyst should actually read a vulnerability. You glance at the Identifiers group and you get the full picture in one pass.
The CVE tells you which specific flaw or flaws you are dealing with, so you can find advisories, patch notes and known exploit details.
The CWE tells you what class of weakness produced it, so you can reason about root cause and look for the same pattern elsewhere.
The CVSS score and vector tell you how severe and how exploitable it is, so you can rank it against everything else in the queue and justify that ranking.
The references give you the trail back to authoritative sources, and the MITRE techniques connect the flaw to attacker behavior. Read together, these fields turn a bare scanner result into a decision-ready record. None of them alone is enough. CVE without CVSS leaves you guessing at priority. CVSS without CVE leaves you with a severity grade and no way to find the patch. CWE without either leaves you with a category and no instance to act on. The template insists on all of them at once because real triage needs all of them at once.
There is also a deeper reason the template carries every dimension together. Consistency. When the same template matches a hundred findings across a dozen scanners, every one of those findings inherits the identical CVE list, CWE list, CVSS data and references. The identifiers stop being whatever each scanner happened to populate and become a single, authored, consistent source of truth. That is enrichment turning noisy multi-scanner output into uniform finding context.
Why a Template Library Stores All Three
It is worth pausing on the design choice. Why does PMAP keep CVE, CWE and CVSS bundled into a reusable template at all, rather than just reading whatever each scanner reports per finding?
Because scanners disagree, and findings repeat. A vulnerability template is a scanner-agnostic, reusable definition of a known vulnerability class. It is authored once, centrally, by security content authors, and then matched automatically against incoming findings from any scanner, whether that is Tenable, Qualys, Rapid7, a DAST tool or a SAST tool. The template is the single place where the canonical CVE list, CWE list, CVSS scoring and remediation guidance live.
This matters for three practical reasons.
First, normalization. Different scanners populate identifiers inconsistently. One may report a CVE and no CWE. Another may report a plugin ID and a vague title. When a template matches the finding, the finding inherits the full, authored set of identifiers regardless of how sparse the original scan result was. The template fills the gaps. CVE, CWE and CVSS arrive complete and consistent every time.
Second, reuse. The same vulnerability class shows up across hundreds of assets and across repeated scans. Authoring the CVE, CWE and CVSS data once on a template, then matching it everywhere, means your content team curates the truth in a single record instead of correcting the same identifiers finding by finding. Update the template once and every future match reflects the change.
Third, multi-language and remediation context travel with the identifiers. The same template that carries the CVE, CWE and CVSS also carries remediation guidance and descriptions in base, Turkish and English variants, so the moment a finding inherits the identifiers it also inherits the fix guidance in the right locale. The identity, the class, the severity and the cure all arrive together because they all live on the same template.
That is the case for a template library. It converts three abstract identifiers into reusable, consistent, decision-ready context that any scanner result can inherit.
From Identifier to Decision
Knowing what CVE, CWE and CVSS mean is the foundation. Turning them into an actual remediation decision is the goal. PMAP closes that gap with its Smart Match engine, and understanding it shows you why fluent reading of these three identifiers pays off.
When a finding arrives from a scanner, PMAP needs to attach the right template so the finding inherits the right CVE, CWE, CVSS and remediation context. It does this with a prioritized, four-stage match pipeline, and the priority order is built directly on the identifier hierarchy this article has described.
The first and strongest stage is CVE exact match. If the incoming finding carries a CVE identifier that overlaps any template’s cve_ids[] array, that is a deterministic, exact hit, and it is assigned the highest possible confidence. This is identity matching identity. It is the most reliable signal available, which is exactly why CVE sits at the top.
The second stage is plugin key match. If no CVE overlaps, PMAP tries the scanner-specific plugin identifiers, the Nessus plugin IDs and Qualys QIDs stored on the template, matching them against the keys the scan reported. This is deterministic too, just one notch below CVE because it is scanner-specific rather than universal.
The third stage is fuzzy title match. When neither identifier route resolves, the engine compares the finding’s title against template names using text similarity, and the confidence reflects how close the match is. This is the fallback for findings that arrive without clean identifiers.
The fourth stage is the manual fallback, surfacing the most recently updated active templates at low confidence so an analyst can pick the right one by hand.
The pipeline returns ranked candidates with a best match and a stated confidence, and the analyst confirms before anything is applied. Once a template is selected, its auto-fill bundle injects the template’s curated fields into the finding. That is the moment the abstract identifiers become operational. The finding now carries the CVE that names it, the CWE that classifies it, the CVSS data that grades it, and the remediation that fixes it. The taxonomy enrichment aligns the finding to PMAP’s canonical finding taxonomy, so the inherited data slots into the same structure every other finding uses.
The practical lesson for a practitioner is this. The cleaner the identifiers on your findings, the higher up the pipeline they match, and the more deterministic and confident the enrichment is. A finding that arrives with a real CVE matches at the top stage with full confidence. A finding that arrives with only a vague title falls to fuzzy matching and needs more human judgment. Fluency in CVE, CWE and CVSS is not academic. It is what lets you understand why some findings enrich themselves cleanly and others need your attention.
If you want the broader picture of how PMAP turns raw scanner output into enriched, decision-ready findings, the vulnerability intelligence and enrichment pillar covers the full enrichment story end to end. For a closer look at how the matching engine ranks and applies templates, see how Smart Match template matching works. And if you want to go deeper on the scoring system alone, CVSS scoring explained breaks down the score and bands in detail.
Bringing It Together
Three short codes, three different jobs. CVE is the identity of a specific known vulnerability, a shared global name maintained under the MITRE CVE Program and enriched in the NVD. CWE is the class of weakness behind it, a MITRE taxonomy that lets you reason about patterns and root causes rather than isolated incidents. CVSS is the severity grade, a FIRST-maintained scoring system that produces both a comparable number and a vector string explaining how that number was reached. Identity, class, severity.
The reason these three matter so much in practice is that no single one of them is sufficient. Triage needs the name to find the fix, the class to understand the cause, and the score to set the priority. That is why a PMAP vulnerability template carries all three together in one Identifiers group, keeps the CVSS score and your operational severity as separate fields, and stores CVE and CWE as arrays so a class can carry several identities. And it is why the Smart Match pipeline is built on the identifier hierarchy, matching on CVE first because identity is the strongest signal there is.
Learn to read these three fields fluently and almost every scanner result, advisory and finding record becomes legible at a glance. You stop seeing three confusing codes and start seeing a complete, decision-ready description of a vulnerability.
Ready to see it in action? Read the VulnDB Smart Match datasheet and turn CVE, CWE and CVSS into auto-applied finding context.
Frequently Asked Questions
What is the difference between a CVE and a CWE?
A CVE is the identity of one specific, publicly disclosed vulnerability, usually in a particular product or version, named under the MITRE CVE Program so every team refers to the same flaw. A CWE is the class of underlying weakness that produced it, such as cross-site scripting or SQL injection, and many separate CVEs can share the same CWE. In short, CVE names an instance and CWE names the category. In PMAP a vulnerability template stores both, in separate cve_ids[] and cwe_ids[] arrays, so a finding inherits its specific identity and its weakness class at the same time.
Is a CVSS score the same as severity?
Not necessarily. The CVSS score is the numeric output of the CVSS scoring system, a value from 0.0 to 10.0 that reflects theoretical severity under standard assumptions defined by FIRST. The severity your platform tracks can differ once you factor in context the base score does not see, like asset exposure or compensating controls. PMAP stores cvss_score and severity as separate fields on a template precisely so you can keep the standardized CVSS number while also recording an operational severity that fits your environment. One does not overwrite the other.
Can one vulnerability have multiple CVEs or CWEs?
Yes. A single vulnerability class, as captured in a PMAP template, can carry several CVE identifiers and several CWE identifiers, which is why both are stored as arrays rather than single values. Multiple disclosed flaws that share the same remediation and context can sit on one template, and a flaw can reflect more than one weakness class. The array structure also enables exact-match lookups, so a scanner result carrying any one of those CVEs can match the template.
Where do these identifiers live in a vulnerability template?
They live together in the Identifiers group of the template. That group holds the cve_ids[] array, the cwe_ids[] array, the cvss_vector string, the cvss_score float, a references[] array of source links, and the mitre_technique_ids[] array. Grouping them together means an analyst reads the full identity, class and severity picture in one pass, and any finding the template matches inherits all of those fields at once.
How do I read a CVSS vector string?
A CVSS vector is a structured breakdown of how the score was calculated. It lists metrics like Attack Vector (AV), Attack Complexity (AC), Privileges Required (PR), User Interaction (UI) and Scope (S) for exploitability, then Confidentiality, Integrity and Availability impact (C, I, A). Reading it tells you whether a flaw is remotely reachable, how easy it is to exploit and what an attacker gains, which is context the bare number hides. PMAP stores cvss_vector alongside cvss_score so the vector is always available next to the headline figure.
Why does PMAP store CVE, CWE and CVSS on a reusable template instead of per finding?
Because scanners report identifiers inconsistently and the same vulnerability class repeats across many assets and scans. A template is a scanner-agnostic definition authored once, then matched automatically against findings from any scanner. When it matches, the finding inherits the full, consistent set of CVE, CWE and CVSS data regardless of how sparse the original scan result was. Curating the identifiers once on a template, rather than correcting them finding by finding, keeps the data normalized, reusable and decision-ready.
Which identifier does PMAP match on first?
CVE. PMAP’s Smart Match engine runs a prioritized four-stage pipeline, and CVE exact match sits at the top with the highest confidence because identity matching identity is the most deterministic signal available. If no CVE overlaps, the engine falls to scanner plugin keys, then to fuzzy title matching, then to a manual fallback. The cleaner the identifiers on an incoming finding, the higher up the pipeline it matches and the more confident the enrichment.
