AI Writes Code That Compiles. Security Is Where It Fails

AI code security is now the only part of AI-assisted development that has not improved. The argument about whether these models can write working code is over, and the answer was yes: modern models produce syntactically correct code almost 100% of the time. That settles the question engineering teams spent two years asking, and quietly replaces it with a harder one. Correct according to whom, and safe against what?

Veracode’s 2026 GenAI Code Security Report, published on 28 July 2026, puts a number on the gap. Across the models tested, the average security pass rate is 56%. In the first edition of the same report it was 55%. A year of model progress produced roughly one percentage point of security improvement.

Put the other way round: about 44% of AI code generation tasks introduced a risky security vulnerability.

The failure is uneven, and that is the useful part

A single average hides what engineering leaders actually need to act on. The report breaks results down by weakness class, and the spread is wide enough to change how a team reviews code.

Where models do well: cryptographic algorithm use passes at 87%, and SQL injection at 83%. These are the vulnerabilities with decades of documentation, clear idioms and abundant training examples. The models learned them thoroughly.

Where models fail badly: cross-site scripting passes at just 15%, and log injection at 12%. Nearly nine times out of ten, the generated code carries the flaw.

That pattern deserves a moment. The vulnerabilities an organisation is most likely to assume are solved — because they are old, famous and well documented — are precisely the ones the model handles well. The failures concentrate in context-dependent weaknesses, where safety depends on where the data came from and where it is going. No amount of local pattern matching tells you that. It is a property of the system, not of the snippet.

The practical consequence is that a generic security review, weighted the way reviews have historically been weighted, looks in the wrong place. It inspects the classes the model already gets right.

Reasoning models help less than the marketing suggests

The report also compares categories of model, and the differences are smaller than the positioning implies. Reasoning models average 56% against 51% for non-reasoning models. Coding-specialised models average 51%; general-purpose models average 52%. The strongest performer reaches 68%, while more than half of the models tested land between 50% and 53%.

Read those two middle numbers again. Models specialised for coding scored below general-purpose models. Specialisation in writing code did not produce specialisation in writing secure code, which makes sense once stated: the training objective rewards code that works, and insecure code works.

Choosing a different model is therefore not a security strategy. It is, at best, a few percentage points on a figure that needs to move much further.

Why the numbers barely moved in a year

Between the two editions the industry shipped substantially more capable models. Syntax correctness approached ceiling. Benchmarks for reasoning and for tool use improved visibly. Security moved from 55% to 56%.

The most plausible reading is that security is not a capability the models are being optimised for, because it is not what the dominant evaluations measure. A model is rewarded for producing code that satisfies the request. A vulnerability satisfies the request. Until the objective changes, the number has little reason to move, and planning should assume it will not.

What this changes in practice

If generation is effectively free and nearly always syntactically valid, the constraint on delivery moves entirely to verification. Review stops being a formality applied to human work and becomes the only thing standing between a 56% pass rate and production.

For engineering leadership that implies three concrete shifts. Security review has to be instrumented rather than assumed, because the failure is invisible at the point of generation — the code looks right. It has to be weighted towards the weakness classes where models demonstrably fail, rather than spread evenly across a checklist written for human error patterns. And it has to run in the pipeline rather than depend on whoever happens to pick up the pull request.

None of this is an argument against AI-assisted development. It is an argument that AI code security is a property of the process around the model, not of the model, and that the organisations treating it as a procurement decision are measuring the wrong thing. The code will compile. That was never the risk.

Source: Veracode, 2026 GenAI Code Security Report, 28 July 2026.