Common Weakness Enumeration (CWE)

The Common Weakness Enumeration (CWE) is a hierarchically organised catalogue of software and hardware weakness types, maintained by MITRE with support from the cybersecurity community. Each CWE entry describes a specific weakness category — a type of flaw in design, code, or architecture that can lead to vulnerabilities — rather than a specific vulnerability in a specific product. For example, CWE-79 describes Cross-Site Scripting as a weakness type; any specific web application vulnerability involving reflected XSS would be assigned the relevant CVE for that product, but its root cause would be mapped to CWE-79. The CWE catalogue contains over 900 weakness types, organised in a taxonomy from abstract (CWE-693: Protection Mechanism Failure) to concrete (CWE-120: Buffer Copy Without Checking Size of Input).

CVE (Common Vulnerabilities and Exposures) and CWE are complementary but distinct systems:

• CVE identifies specific vulnerability instances in specific products at specific versions — 'CVE-2021-44228 is a vulnerability in Apache Log4j 2.x'.
• CWE identifies the type of weakness that caused the vulnerability — 'CVE-2021-44228 is caused by CWE-917: Improper Neutralisation of Special Elements used in an Expression Language Statement'.

CVE entries in the NVD typically include one or more CWE mappings to describe the underlying weakness type. CVSS scores in the NVD are supplemented by CWE information to help security teams understand root causes. For manufacturers, CWE mappings of known vulnerabilities in their products provide essential data for root cause analysis, identifying systematic weakness patterns in their codebase.

CWE is particularly valuable for the threat modelling and secure development lifecycle activities required by the CRA's Annex I essential requirements. Manufacturers can use CWE to:

• Identify design-level weaknesses: MITRE's CWE Top 25 Most Dangerous Software Weaknesses is an annually updated list of the most commonly exploited weakness types, providing a prioritised checklist for code review and design review.
• Pattern-match against past vulnerabilities: If a manufacturer has had multiple CVEs with the same CWE root cause, this signals a systematic weakness in their development process that should be addressed through training, tooling, or design pattern changes.
• Configure static analysis tools: SAST tools can be configured to detect specific CWE patterns — focusing scanning effort on the weakness types most relevant to the product's technology stack.
• Structure security requirements: Translating Annex I essential requirements into concrete CWE-based absence requirements (e.g., 'no instances of CWE-89 in database interaction code').

Security advisories published by manufacturers should include the CWE identifier(s) for the underlying weakness type in addition to the CVE identifier and CVSS score. This practice, increasingly expected by vulnerability management tools and security researchers, provides important context: a CVSS 9.8 vulnerability caused by CWE-798 (Use of Hard-coded Credentials) requires a different remediation approach than a CVSS 9.8 vulnerability caused by CWE-787 (Out-of-bounds Write). CSAF (Common Security Advisory Framework) documents support CWE fields natively. Including CWE mappings in CSAF advisories enables downstream vulnerability management tools to correlate advisories with code review findings and helps the security community understand manufacturer weakness patterns over time. CVD Portal's advisory generation supports CWE field inclusion in CSAF output.