What is a CWE, and why do AI security tasks cite them?

CWE stands for Common Weakness Enumeration. It is a public catalogue of the kinds of mistakes in software that lead to security problems. Each kind gets a number and a short name. CWE-79, for example, is cross-site scripting, and CWE-89 is SQL injection. The list is maintained by MITRE, a nonprofit research organization, and it is used across the security industry as a shared vocabulary.

When a lab looks at a set of security tasks, it asks what kinds of weakness they cover. A CWE number is the cleanest way to answer.

CWE, CVE and OWASP are different things

People mix these up, and the difference matters.

Name	What it is	Example
CWE	A type of weakness, a pattern of mistake	CWE-89, SQL injection
CVE	One specific flaw in one specific product, with its own number	A flaw in a named version of a program
OWASP Top 10	A short ranked list of the most serious risks for web applications, with versions for APIs and others	Injection, broken access control

A CVE is one instance, and a CWE is the category it belongs to. The OWASP lists group risks, and the project maps its categories to CWE numbers. The United States National Vulnerability Database, run by the National Institute of Standards and Technology, labels published flaws with the CWE they fall under.

MITRE also publishes a yearly ranking, the CWE Top 25 Most Dangerous Software Weaknesses. The 2024 list came out in November 2024 and is built from published flaws and their severity. It shows which categories are common and which matter most.

Why AI security tasks cite them

Labs use CWE for four reasons.

1. Coverage. A set of 500 tasks that all test one kind of weakness is worth less than a set that spans many. A list of CWE numbers shows the spread at a glance.
2. Gaps. A lab can compare the set to the public ranking and see which common weaknesses are missing.
3. Comparison. Two sets from two builders can only be compared if they use the same names.
4. Grouping for training. A lab can train a model on some categories and test it on others, which shows whether it generalizes.

This is why a datasheet for a security environment set usually has a table: one row per CWE, with the number of tasks, the languages and frameworks used, and how hard they were measured to be.

What a builder should prepare

If you built tasks around software weaknesses, write down:

• the CWE number for each task, and where several apply, the main one;
• how many tasks per category and per language;
• whether each weakness is found in made-up software, which is what makes the task safe to license;
• whether the task started from a real flaw in real software, and if so whether it was reported to the maker and fixed.

The last point decides more than any other. A task built on a real flaw that has not been reported puts the builder in a difficult spot, and labs know it. Responsible disclosure comes first, and your own counsel can tell you what your contracts require.

Where this fits

Security companies keep alerts, case notes and detection logic that already mention these categories. Read what a cybersecurity company can license for what is usually possible, and our page on selling RL environments for the environment side. The glossary has a short entry for CWE. A related idea, the exploit chain, is how a task combines several weaknesses into one path.