Each CVE corresponds to one or more CWEs. A CVE can result from multiple types of flaw: CWE-200 (information exposure) can be root-cause, CWE-269 (improper access control) can be contributing. Understanding all CWEs of a CVE gives you complete context.
What is CWE
CWE (Common Weakness Enumeration) is a standardised categorisation of the types of security flaws in software. Examples: CWE-89 is SQL Injection, CWE-79 is Cross-Site Scripting (XSS), CWE-20 is Improper Input Validation. A CVE (specific vulnerability) corresponds to one or more CWE categories. Example: CVE-2021-44228 (Log4Shell) is categorised as CWE-502 (Deserialization of Untrusted Data). CWE helps understand the technical nature of the problem: it is not just 'there is a vulnerability', but 'there is a vulnerability because there is insecure deserialisation'. CWE is useful for remediation: if you understand it is CWE-502, you know how to avoid it in the future (do not deserialise untrusted data).
Why it matters
For a CISO or developer, CWE is educational and preventive. CVE tells you 'you have this specific problem'. CWE tells you 'you have this *class* of problem, typical in applications that do X'. If you deploy multiple applications, all CWE-79 (XSS), you know they have similar vulnerability types and require similar fixes (input validation, output encoding). CWE is also strategic: if you analyse your last 5 years of vulnerabilities and find 50% are CWE-79 (XSS), it means your code review process is not detecting XSS. You can invest in SAST (static analysis) that detects XSS specifically. CWE transforms a specific problem into an identifiable pattern, enabling systematic prevention.
Key points
The most common CWEs are those appearing in most breaches: CWE-79 (XSS), CWE-89 (SQL Injection), CWE-20 (Improper Input Validation), CWE-200 (Exposure of Sensitive Info). If training, code review and SAST focus on preventing these, you significantly reduce risk.
CWE is hierarchical: there are general CWEs (CWE-693 'Protection Mechanism Failure') and specific ones (CWE-79 'XSS'). For remediation, you need the specific one. For defence-in-depth strategy, you understand the general one.
CWE is more accessible than CVE for developers. A developer does not use CVE numbers daily, but preventing CWE-79 in their code does. CWE is the bridge between abstract security and concrete code.
Example: remediation based on CWE
A CISO analyses the last 20 vulnerabilities in their web application. Finds: 8 are CWE-79 (XSS), 7 are CWE-89 (SQL Injection), 5 are CWE-20 (Improper Input Validation). Clear pattern: lack of input validation. Implements: (1) Centralised validation framework: input whitelist, automatic output encoding. (2) SAST that specifically detects CWE-79 and CWE-89. (3) Developer training on CWE-79 and CWE-89. (6 months later, of 15 new vulnerabilities, only 1 is CWE-79. Most are now CWE-434 (insecure file upload) which the team had not seen before. Same approach: detect the pattern, train, implement preventive control. Without CWE, it would be 'we have fixed problems', without understanding what type of problems. With CWE, it is 'we have fixed input validation, next step is upload security'.
Common mistakes
- Confusing CVE and CWE. CVE is a specific vulnerability in a specific software version. CWE is a general type of flaw. One CVE can exist in multiple applications because they all share the same CWE. They are not interchangeable.
- Not analysing the pattern of CWEs in your vulnerabilities. If all are CWE-79, the problem is not that you have one, it is that your process is not detecting CWE-79. Investing in CWE-79 prevention (SAST, code review, encoding) is more effective than patching each instance.
- Ignoring CWE in remediation and only patching 'the specific bug'. If you only remediate the CVE-2023-XXXXX without understanding its CWE, a similar flaw is probably elsewhere in your code. Remediation by CWE is more effective.
- Not using CWE for developer training. Teaching 'avoid XSS' is abstract. Teaching 'CWE-79 occurs when you do not validate input, use htmlspecialchars()' is concrete and actionable.
Related terms
Related services
This concept may be related to services such as:
Frequently asked questions
How do CVE, CWE and CVSS relate?
CVE identifies a specific vulnerability (e.g. Log4Shell). CWE categorises the type of flaw (e.g. Deserialisation). CVSS scores technical severity (e.g. 10/10). A CVE has a CVSS score and corresponds to one or more CWE categories.
What are the most common CWEs?
According to OWASP Top 10 and historical data: CWE-79 (XSS), CWE-89 (SQL Injection), CWE-20 (Improper Input Validation), CWE-200 (Exposure of Sensitive Info), CWE-434 (Unrestricted File Upload). Preventing these covers most web vulnerabilities.
How do I use CWE to improve security in development?
Analyse your recent vulnerabilities, categorise by CWE, identify patterns. If 50% are CWE-79, focus on XSS prevention (SAST rules, code review, output encoding). Train the team specifically on that CWE. Repeat quarterly.
Is CWE only for software or also infrastructure?
CWE is mainly for logical flaws in software (input validation, authentication, authorisation). Infrastructure flaws (misconfiguration, weak encryption) have CWE categories but are less commonly used. For infrastructure, CSPM and audits are more useful.