What does CWE stand for: Common Weakness Enumeration. It's a community-developed, publicly maintained list of software and hardware weakness types — categories of coding or design flaws like SQL injection, buffer overflow, or improper input validation — maintained by MITRE with contributions from vendors, researchers, and government agencies. Where a CVE identifies one specific, real-world vulnerability instance (a particular flaw in a particular version of a particular product), a CWE identifies the general class of weakness that vulnerability belongs to, which is what makes CWE the taxonomy that connects individual bugs to the patterns behind them.
How is a CWE different from a CVE?
A CVE (Common Vulnerabilities and Exposures) is a specific, catalogued instance — CVE-2021-44228, the Log4Shell vulnerability, is one entry describing one flaw in one piece of software. A CWE is the category that instance falls under — Log4Shell is classified under CWE-502 (Deserialization of Untrusted Data) among others, because the underlying weakness pattern (accepting and processing untrusted serialized input as if it were trusted) shows up across many unrelated CVEs in completely different codebases. This relationship is why CVE records typically reference one or more CWE IDs: it lets someone looking at a specific vulnerability understand not just what happened, but what class of mistake produced it, and whether that same class of mistake might exist elsewhere in their own code.
Why does a weakness taxonomy matter if you already have CVE data?
Because CVE data tells you what happened after the fact, while CWE data tells you what to look for before it happens again. If a team keeps getting CVEs traced back to CWE-89 (SQL Injection) across multiple projects, that's a signal pointing at a systemic gap — probably a lack of parameterized queries as a default pattern — not a series of unrelated unlucky incidents. Static analysis tools use CWE categories as the backbone of their rule sets specifically because weaknesses are the thing a scanner can actually detect in source code before an exploit exists; a scanner can't know about a CVE that hasn't been assigned yet, but it can recognize the CWE-79 (Cross-Site Scripting) pattern of unescaped user input reaching an HTML response, regardless of whether that specific instance has ever been publicly disclosed.
What does the CWE Top 25 actually rank, and why does it change?
The CWE Top 25 Most Dangerous Software Weaknesses, published annually, ranks weakness categories by how frequently and severely they show up across a large corpus of real CVE data from that year — it's a data-driven list, not a subjective one, recalculated using a scoring formula that weighs both prevalence and average severity. Categories like out-of-bounds write, cross-site scripting, and SQL injection have appeared near the top for years running, which says less about the list being stale and more about how persistent these weakness classes are across the industry regardless of how much guidance exists about avoiding them. Movement in the rankings year over year is often a useful signal of where the industry's actual failure modes are shifting — for instance, weaknesses tied to memory safety have drawn renewed attention as scrutiny of memory-unsafe languages like C and C++ has intensified industry-wide.
Where does CWE show up outside of CVE records and scan reports?
It's the backbone of the OWASP Top 10 as well — each OWASP category maps to a cluster of underlying CWEs, so "Broken Access Control" (OWASP's top category in its most recent list) isn't a single weakness but a grouping of related CWEs like improper authorization checks and insecure direct object references. Compliance frameworks and secure-coding standards reference CWE IDs directly for the same reason scanners do: it's a stable, versioned vocabulary that doesn't change meaning between tools or teams. When a security report says a finding maps to "CWE-798: Use of Hard-coded Credentials," that's a precise, tool-agnostic description any engineer can look up and understand, independent of which specific product generated the report.
FAQ
Is CWE the same organization as CVE?
They're related but distinct programs, both stewarded with MITRE's involvement. CVE is the vulnerability instance database; CWE is the weakness-type taxonomy. Many CVE records reference the CWE category their flaw belongs to.
How many CWEs are there?
The CWE list includes several hundred distinct weakness categories, organized hierarchically from broad classes down to very specific weakness types, and it's updated periodically as new patterns are identified.
Does every vulnerability have a CWE mapping?
Most well-documented CVEs do, but mapping isn't always precise — some vulnerabilities involve multiple weakness types, and CWE mapping quality across the broader CVE dataset varies by how thoroughly each record was researched at disclosure time.
Is CWE only relevant to software?
No — the taxonomy also covers hardware weaknesses, reflecting a broader scope MITRE expanded to as hardware security research matured. Software weaknesses remain the far larger and more actively referenced portion of the list.
How Safeguard Helps
Safeguard's SAST engine tags findings with their underlying CWE classification alongside any related CVE, so a team can see not just what specific issue was found but which weakness pattern keeps recurring across their codebase — turning individual fixes into a signal for where secure-coding training or default patterns actually need to change.