CWE stands for Common Weakness Enumeration, a community-maintained catalog, run by MITRE, of the underlying types of software and hardware weaknesses that lead to vulnerabilities — things like "improper input validation" (CWE-20) or "SQL injection" (CWE-89) as categories, not specific instances. Where CVE identifies one particular vulnerability in one particular product, CWE classifies the pattern of flaw behind it, which is why almost every CVE entry and every scanner finding gets tagged with a CWE ID as its "type."
How is CWE different from CVE?
CVE and CWE answer different questions: CVE answers "what specific flaw exists in this specific product and version," while CWE answers "what kind of coding or design mistake is this." A single CWE, like CWE-79 (cross-site scripting), covers thousands of individual CVEs across thousands of different applications, because XSS as a weakness pattern shows up wherever user input reaches a page without proper encoding, regardless of the specific product. When a vulnerability scanner or SAST tool reports a finding, it typically cites both: the CVE if it's a known vulnerability in a third-party dependency, and the CWE that classifies what kind of weakness it is, whether the finding came from a known CVE or a static analysis result in your own code.
Why does CWE matter for tools that scan your own code?
CWE matters especially for SAST tools because most of what static analysis finds in your own code will never get a CVE — CVEs are assigned to identifiable products and versions, not to a specific line of business logic in your internal application. When a SAST scan flags a hardcoded credential or an unvalidated redirect in your codebase, there's no CVE to reference because it's not a published vulnerability in a distributable product — but the CWE ID tells you exactly what class of weakness it is (CWE-798 for hardcoded credentials, CWE-601 for open redirect), which lets you search for known remediation guidance and compare severity across completely different codebases using a consistent taxonomy.
How does CWE relate to the OWASP Top 10?
The OWASP Top 10 groups multiple related CWEs into ten broader risk categories aimed at prioritization, while CWE itself is far more granular — currently covering many hundreds of individual weakness types. OWASP's "Injection" category, for instance, maps to a cluster of CWEs including SQL injection (CWE-89), OS command injection (CWE-78), and LDAP injection (CWE-90). Think of OWASP Top 10 as the executive summary for prioritizing what to fix first industry-wide, and CWE as the detailed dictionary a tool or an engineer actually uses to name the specific weakness found. CWE also feeds into MITRE's annual "CWE Top 25 Most Dangerous Software Weaknesses" list, which ranks weakness types by how frequently and severely they appear across real, published vulnerabilities.
How is the CWE list actually organized?
CWE is organized as a hierarchy, not a flat list, with broad "pillar" weaknesses at the top (like CWE-664, "Improper Control of a Resource Through its Lifetime") branching down into progressively more specific classes and base weaknesses. This hierarchy matters practically because a tool can tag a finding at whatever level of specificity it can actually determine — a generic input validation issue versus a precisely identified SQL injection instance — and both tags remain valid and comparable within the same taxonomy. MITRE maintains the full catalog publicly at cwe.mitre.org, along with detailed descriptions, real-world examples, and mapped relationships to CVE entries and OWASP categories for each entry.
Why does this matter for tool output and compliance reporting?
CWE gives you a stable way to compare and aggregate findings across different scanners, languages, and years, which matters both for triage and for demonstrating security posture to auditors. A compliance framework or a customer security questionnaire asking "what classes of vulnerabilities does your SDLC catch" is really asking for CWE coverage — whether your SAST and DAST tooling actually detects the weakness types that matter for your risk profile. Platforms running SAST/DAST scanning that tag every finding with a CWE ID make it straightforward to answer that question with evidence instead of a vague description of "we scan for vulnerabilities."
FAQ
Who maintains the CWE list?
MITRE maintains CWE, the same organization that maintains CVE, with contributions from a broad community of security researchers and vendors through the CWE Program.
Does every vulnerability have both a CVE and a CWE?
Only vulnerabilities in identifiable, distributable products get a CVE. Nearly all of them get a CWE classification, but plenty of CWE-classified findings — especially in custom application code — never get an individual CVE because there's no product/version to register.
Is CWE the same thing as OWASP?
No. OWASP is an organization that publishes guidance including the Top 10 risk categories; CWE is MITRE's separate, more granular weakness taxonomy. OWASP's Top 10 references and groups specific CWEs.
How many CWE entries are there?
The catalog is large and actively maintained, with new entries added over time; rather than memorizing a count, it's more useful to know that entries range from broad "pillar" weaknesses down to very specific, narrowly defined ones.