What is a CWE? Common Weakness Enumeration, explained
A CWE (Common Weakness Enumeration) identifies a class of software weakness - a category like SQL injection (CWE-89) or use-after-free (CWE-416) - rather than one specific vulnerability. Where a CVE names a single flaw in a specific product, a CWE names the kind of mistake. Static analysis findings are keyed to CWEs because a scanner detects weakness types, and the CWE tells you what class of problem you are looking at.
A CWE - Common Weakness Enumeration - identifies a type of software weakness. Where a CVE names one specific vulnerability in one specific product, a CWE names the category the vulnerability belongs to: CWE-89 is SQL injection, CWE-79 is cross-site scripting, CWE-416 is use-after-free. It is a taxonomy of the ways software goes wrong, and it is the vocabulary static analysis speaks.
Class versus instance
The cleanest way to hold the distinction:
- A CWE is the kind of mistake: “SQL injection” as a general weakness.
- A CVE is a specific occurrence of such a mistake in real software: one particular SQL injection, disclosed, in one product version.
One CWE class underlies countless CVEs - every SQL injection ever catalogued is an instance of CWE-89. The relationship is category to member. This is why the two identifiers show up in different places: vulnerability databases and SBOM matching deal in CVEs (specific disclosed flaws in dependencies), while static analysis deals in CWEs (weakness types found in your own code).
Why static analysis findings carry CWEs
When a SAST engine finds attacker-controlled input reaching a database query, it has not found a catalogued CVE - it has found a weakness in your code that has no public identifier. The honest, useful label is the weakness class: CWE-89, SQL injection. That label does real work:
- It communicates the category unambiguously to any developer or tool that knows the taxonomy.
- It carries impact and remediation context, because each CWE entry describes the consequences and the fixes for its class.
- It enables coverage measurement: you can ask which CWE classes a tool detects, and check them against the classes that matter.
This is why a serious static analyzer maps every finding to a CWE - it is the difference between “something looks wrong here” and “this is a CWE-89 SQL injection, here is why it matters and how to fix it.”
The CWE Top 25 and coverage
Because CWEs categorize weaknesses, they can be ranked. The CWE Top 25 is a regularly-updated list of the most dangerous and prevalent weakness classes, derived from real vulnerability data, and it functions as a coverage yardstick: security teams verify that their tooling detects the weakness types most likely to cause harm. Alongside the OWASP Top 10, which groups risks at the application level, the CWE Top 25 is one of the standard reference points for judging whether a scanner covers what matters. The SecuNexa engines key every finding to its CWE and publish their coverage against these lists, so “does it detect the weaknesses that count” is a checkable question rather than a claim.
Frequently asked questions
What is the difference between a CWE and a CVE?
A CWE is a category of weakness; a CVE is one specific instance of a vulnerability in a specific product. CWE-89 is 'SQL injection' as a class; a CVE is one particular SQL injection in one particular software version. Static analysis reports CWEs because it finds weakness types in your code; vulnerability databases use CVEs because they catalog specific disclosed flaws.
Why are SAST findings labeled with CWEs?
Because a static analyzer detects patterns of weakness, not catalogued disclosures. When it finds attacker-controlled data reaching a query, the accurate label is the weakness class - CWE-89, SQL injection - not a CVE, because your code's flaw has not been assigned a public identifier. The CWE communicates the category, its impact, and how to remediate it.
What is the CWE Top 25?
A regularly updated ranking of the most dangerous and prevalent software weakness classes, derived from real-world vulnerability data. It is widely used as a coverage target: security teams check that their tools detect the weakness types in the Top 25, since those are the classes most likely to cause real harm.