What does a CWE identifier claim about a flaw that a CVE identifier does not?

## Two schemes, two questions People say "CVE" and "CWE" in the same breath and treat them as two spellings of the same thing. They are not. They answer different questions, they are produced by different processes, and only one of them is about your product. **A CVE identifier is an instance claim.** It says: there is a specific flaw, in a specific product, in specific versions. It is a name for *one occurrence* so that a vendor, a researcher, an operator and an advisory writer can all be sure they are discussing the same thing. Identifiers are issued by CVE Numbering Authorities (CNAs) — organisations, mostly vendors and coordinators, that hold a scope inside the CVE Program and may number flaws within it. **A CWE identifier is a class claim.** It says: this flaw is an instance of a recurring kind of mistake. CWE (Common Weakness Enumeration) is a taxonomy of weakness *types* maintained by the CWE program at MITRE with community contribution. Entries are written to be product-independent and language-independent wherever possible, precisely so the same entry can describe a mistake made by thousands of unrelated teams. ## Who decides the mapping This is the part candidates miss. The weakness class attached to a flaw is **not a property of the identifier**; it is an editorial judgment recorded by whoever wrote the record. A CNA may supply a weakness class in the CVE record's problem-type field. NVD analysts may attach one when they enrich a record, and NVD works from a reduced view of CWE rather than the full list, with explicit placeholders when nobody could tell — an "insufficient information" entry and an "other" entry exist for exactly that reason. That has two consequences worth saying out loud in an interview: - The class attached to a record can be wrong, can be revised, and is sometimes deliberately vague because the person mapping never saw the source. - Two records describing near-identical bugs can carry different weakness classes because two different people mapped them. ## The cardinality - **Many instances, one class.** An out-of-bounds write in a printer driver and one in a video codec are unrelated products, unrelated vendors, unrelated fixes — and both are `CWE-787`. The class is making a *recurrence* claim: this mistake keeps happening. - **One instance, several classes.** A flaw can be described as a chain: one weakness makes a second reachable. Records sometimes carry more than one class for that reason. - **Classes with no instance.** A weakness entry exists whether or not anybody has ever numbered a public flaw of that shape. The taxonomy is a vocabulary, not a count of known bugs. ## What a weakness class never asserts A weakness class carries no product, no version range, no vendor, no fix, no exploit, and no severity. Someone who reads `CWE-732` off a scan output and concludes "we have a known vulnerability" has confused the vocabulary with a claim about their estate. Equally, someone who says "we are clean on CWE-787" has said nothing testable: the class describes a shape of mistake, and absence of a *label* is not absence of the *mistake*. ## Why interviewers open here Because the confusion is expensive downstream. A register that mixes instance identifiers and class labels in one column cannot be counted: one row is a thing you can patch and close, the other is a category that will never be "closed" because the class does not belong to you in the first place. The two schemes also age differently — CWE is versioned, entries are added, split, renamed and deprecated as the community's understanding changes, so a class label recorded years ago may point at an entry that has since been restructured. ## The one-line version A CVE identifier answers *which flaw*. A CWE identifier answers *what kind of mistake*. Different authorities assign them, the link between them is a judgment somebody made, and the class label alone tells you nothing about whether anything in your estate is broken.