Nearly half of AI-generated code fails a security test. Shift-left was never going to be enough

What the report says

The numbers are consistent in a way that should end a few arguments. Model size has essentially no effect: large models passed 53 per cent of security tests, medium 51, small 51. Reasoning models edge ahead, 56 against 51. Models specialised for coding are no safer than general-purpose ones, 51 against 52. The best model in the summer 2026 dataset reached 68 per cent, six of eleven models clustered between 50 and 53, and last year's leader had been at 72. Even the best got worse.

Some vulnerability classes are far worse than the average. Against cross-site scripting, the pass rate was 15 per cent, which is to say the model shipped the flaw 85 times in a hundred. Veracode's own conclusion is that model selection has quietly become a security decision, and that AI now authors roughly half of all committed code, so the same failure rate applies to half a codebase at a pace no security team can match by reading it.

Why "shift left" was never going to be enough

Shift-left is correct and insufficient. Correct because a vulnerability caught in a pull request is cheaper than one caught in production. Insufficient for three reasons that the report makes hard to avoid.

The generator does not learn from your scanner. A human developer who gets the same finding three times stops writing it. A model gets the same finding three thousand times and writes it again tomorrow, because the pipeline's feedback never reaches the thing producing the code. The scanner is not reducing the rate. It is catching a constant rate at increasing volume.

The scanner has a pass rate too. Static analysis catches the vulnerability classes it has rules for, with the false positives it has always had. The classes where models are worst, injection into templates, authorisation checked on the wrong side, secrets in the wrong place, are among the ones static analysis finds hardest to judge without context. Some of what the model ships will pass the gate.

Nobody reads it. When AI writes half the code, review becomes a sampling exercise. The reviewer reads the diff the model summarised, approves the summary, and the flaw is in the part the summary did not mention. That is not negligence. It is arithmetic.

What has to run after the merge

If a constant share of shipped code is vulnerable, the second line of defence is the one that matters, and it lives in production.

1. Runtime detection for the classes the scanner misses. Application security monitoring that watches real requests for injection, authorisation bypass and credential misuse, and that is tuned for your traffic. A rule that fires on the real attack beats a rule that fires on the pattern.
2. A finding reaches a person. Whether it comes from the scanner or the runtime monitor, a critical finding is a ticket with a name and a date, not a line in a report. In the estates we review, security detections routed to no owner is one of the most consistent findings, and that is the control failing silently.
3. A fix can ship in under an hour. The pipeline that made the AI code fast has to make the patch fast too. If a finding in production cannot become a deploy quickly, the scanner is producing paperwork.
4. Reach is bounded. The service runs with the least permission it needs, so a flaw in one feature is a flaw in one feature. Most of what makes a vulnerability a breach is what the vulnerable code was allowed to reach.
5. Choose the model with the numbers in front of you. The difference between 68 and 50 is real. It is also not a substitute for anything above.
6. Verify, continuously. Someone outside the team tests whether the detections fire and whether the fix held. A control nobody has exercised is a control on paper.

Where we fit

Critical Cloud runs the controls on both sides of the merge. The Code Security accelerator puts Datadog static analysis, software composition analysis and CI visibility into your pipeline in four weeks, with a findings baseline and a triage model so the findings go somewhere. For teams that built the product with AI tools and have no pipeline yet, Critical Launch starts with a Launch Check and builds the gate. On the production side, Critical Support runs the detection, the patching and the access hygiene, routed to a named engineer, with the evidence that it ran. Continuous runtime security validation, with our partner Tarian Labs, is the testing: they check the detections fire, we make sure the fix ships.

We operate the stack. You own the product, and you choose the model. We just make sure the half the model wrote is watched as closely as the half it did not.

Sources

• Veracode, Is AI-Generated Code Secure? Key findings from the 2026 GenAI Code Security Report (infographic, summer 2026 dataset) and the full report. All percentages in this article are Veracode's.
• The ownership pattern is from our own assessments of customer estates. We publish the pattern, not the counts.