
CWE-Bench
CWE-Bench is a collection of test tasks used to check how well an AI system finds security vulnerabilities in real program code. The tasks stem from documented real-world vulnerabilities, whose error type is classified according to the CWE catalog.
CWE-Bench is a test collection for programs that are meant to independently search for security vulnerabilities in software. A security vulnerability is a flaw in program code through which attackers can steal data or take over a system. The name refers to a public catalog called CWE, which sorts such flaws by type, for example “password hardcoded in code” or “input not validated.” The collection contains excerpts from real software where it is already known exactly where the flaw lies and which type it corresponds to. A test subject is presented with the code and is supposed to find the spot. Afterwards, its answer is compared with the stored solution, yielding a numerical grade.
Why finding flaws needs a yardstick
Providers of AI tools like to claim that their system reliably finds security vulnerabilities. Without uniform test tasks, this cannot be verified. Anyone could pick examples that make their product look good. A fixed collection like CWE-Bench removes this freedom, because everyone has to solve the same tasks.
The effort is worthwhile because security vulnerabilities are costly. Large companies employ entire teams that do nothing but check code for weaknesses. If an AI takes over part of this work, it saves a great deal of time. Conversely, an unreliable tool causes damage: it flags harmless spots as dangerous and overlooks the real problems.
The distinction between a benchmark and a proof is important. A good result on CWE-Bench shows that a system can handle these specific tasks. It does not guarantee that it will work the same way in an unfamiliar company project. Experts therefore read such numbers as an indication, not as a seal of approval.
How a task is structured
The basis is formed by documented vulnerabilities from open-source software, whose program code anyone is allowed to inspect. For each vulnerability there are two versions of the project: one before the fix and one after. Comparing the two versions reveals which lines were faulty. These lines form the model solution.
During the test, the AI system only gets to see the faulty version. It is supposed to name the file and line of the vulnerability, and often also the matching CWE type. Afterwards, it is counted how many real vulnerabilities were found and how many reports missed the mark. This second number is called the false-positive rate and is often more decisive in practice than the hit rate.
A well-known extension is CWE-Bench-Java, which is limited to projects in the Java programming language. This restriction has a practical reason: every project must be able to be compiled and run automatically so that the test remains reproducible. This is often cumbersome to set up for old projects. That is why such collections usually comprise only a few dozen to a few hundred cases.
Where the numbers show up
CWE-Bench most often appears in announcements of new language models, i.e., AI systems that process text and program code. Providers such as Google, OpenAI, or Anthropic publish a table of test results for each model. Alongside tasks on mathematics and text comprehension, the ability to find flaws in code increasingly appears there as well.
For investors, these numbers are interesting because a growing market lies behind them. Software security companies sell tools that offer exactly this kind of check. If general-purpose AI models suddenly solve such tasks well, this changes the competitive landscape in the industry.
In practice, the automatic check usually runs in the background when developers submit new code. The system then leaves a comment with a suspicion. A human decides whether the report is correct. CWE-Bench essentially measures how often this human can trust the machine.