Malware
CWE
Also called Common Weakness Enumeration.
CWE is a catalog of kinds of software weakness, such as SQL injection or missing authentication. A CWE describes the pattern; a CVE describes one real product bug that fits it.
How it is measured
Each entry has a number, a name, a description, and examples. CWE-79 is cross-site scripting, CWE-89 is SQL injection, CWE-22 is path traversal. You use them by tagging findings from code review or scanners with the matching number.
Counting by CWE across your findings shows patterns. Ten bugs with CWE-79 in one year say your output escaping is the problem, not ten separate plugins.
Worked example
A security review of a custom booking site yields 14 findings. Six map to CWE-79, three to CWE-352, two to CWE-89, and three are one-offs. The team does not file fourteen tickets; they add an output-escaping helper, wire in CSRF tokens everywhere, and move the two raw queries to prepared statements.
The next review a quarter later finds one CWE-79, in a new template that skipped the helper.
How it differs
A CWE is a class of mistake. A CVE is one instance in a named product and version. You can have many CVEs under one CWE, and a weakness can exist in your own code with no CVE at all because nobody has published it. XSS is a CWE; a specific form plugin's script injection is a CVE.
Common errors
Using a CWE number as if it were a vulnerability you can patch. Searching a CWE number in an advisory feed and expecting a fix. Mapping a finding to the closest-looking CWE and not the right one. Ranking by CWE frequency across the whole internet instead of your own findings. Skipping CWEs because they feel academic.
In practice
When a scanner or auditor reports a finding, ask for the CWE. Tally them quarterly. Whichever class repeats most is where a shared helper, a lint rule, or a framework upgrade will pay back first.