What 45% Means: Securing the Code Your AI Agents Just Wrote

Veracode's Spring 2026 GenAI Code Security Update landed in March, and within days the number was everywhere. 45% of AI-generated code introduces a known OWASP Top 10 flaw. Java comes in worse, with a security pass rate of just 29%, meaning more than seven in ten AI-written Java tasks fail. Every AppSec vendor with a scanner to sell picked up the stat the same week.

That's the tell. When an entire category converges on the same headline number to sell the same product, the number has stopped doing analytical work. It's doing marketing work.

The test measures the model. Not your production risk.

Look at what Veracode actually built. 80 coding tasks, 4 languages, 4 CWEs (SQL injection, cross-site scripting, log injection, insecure cryptography), run against 150+ models with no security prompting. It's a rigorous, controlled way to answer one question: how good are these models at writing secure code out of the box. The answer is "not very," and it hasn't moved in two years even as syntax correctness climbed past 95%.

That's a real and useful finding about model behavior. It is not a finding about your codebase. A synthetic function-completion benchmark tells you nothing about whether the specific flawed pattern your AI agent generated last Tuesday ever gets called, whether the vulnerable dependency it pulled in actually loads, or whether the endpoint it wrote is reachable from the internet or buried behind three feature flags nobody has flipped in a year.

Scanning vendors don't dwell on that distinction, because their product answers the first question. Point a SAST tool at a repo full of AI-generated code and it will confirm, correctly, that a lot of it matches OWASP patterns. What it can't do is tell you which of those matches ever executed. So the pitch becomes "AI writes insecure code, buy more scanning," when the harder and more useful question is which of the code that got flagged is actually running in production, right now, in a reachable path.

Static findings and runtime findings are answering different questions

This is where the OWASP framing quietly does a disservice. OWASP Top 10 categories describe pattern types, not operational risk. A log injection flaw in a batch job that only an internal cron triggers once a night is not the same problem as the same flaw sitting in an authentication handler serving live traffic. Static analysis, including Veracode's own methodology, treats both the same way: present in the code, therefore counted. It's the same limitation the industry runs into everywhere else: static analysis identifies possibility, runtime reveals reality.

Runtime evidence doesn't stop at possibility. It shows what actually loads, what functions actually execute, and what code paths are actually reachable from the outside. Applied to AI-generated code specifically, that distinction matters more, not less, because the volume of code being written is going up while the review time per line is going down. Agents don't get tired writing boilerplate. Teams shipping AI-generated code at agent speed are accumulating static findings faster than any team can triage them by hand. The Veracode number is a preview of what that backlog looks like at scale, and no amount of additional scanning coverage fixes a triage problem.

Runtime is the layer none of these vendors are testing for

Kodem's Vibe Coding Security work starts from the same Veracode-style finding and asks the next question: of the AI-generated code that trips a SAST rule, which of it is invoked at runtime. Runtime SAST correlates each static finding against execution evidence, so a flagged function that never loads drops out of the queue, and a flagged function sitting in a live, internet-facing request path moves to the top of it. The same logic extends to dependencies an agent pulls in on its own: a vulnerable package showing up in a manifest is one signal, and the vulnerable function inside it actually being called by running code is a different, more urgent one.

That reframes the 45% entirely. It's not a number you fix by scanning harder. It's a number you make operational by knowing, function by function, what the AI actually shipped into production and what of that is exploitable today. Teams doing that work aren't asking "how much of our AI-generated code has a flaw." They're asking "which flaw is running," which is a much shorter, much more actionable list. It's the same question running across the rest of the AI application stack, from models and plugins to the code an agent committed an hour ago.

The next stat everyone quotes should be about execution, not generation

The GenAI code security conversation is still stuck at the generation stage: how often do models write bad code. That's a model problem, and it isn't going away soon. Training data won't change overnight, and reasoning gains haven't closed the gap either. The more consequential question is shifting to the execution stage: of everything an agent commits, what actually runs, and what of that is exposed. Vendors who can only answer the first question will keep selling the same stat every time a new model drops. The ones worth listening to will be the ones who can tell you, with evidence, which flaw actually ran.

Frequently Asked Questions

1. What does Veracode's 45% AI code security stat actually mean? It means that across Veracode's Spring 2026 testing of 150+ AI models on 80 coding tasks covering four vulnerability types, only 55% of AI-generated code samples passed security checks, so 45% introduced a flaw mapped to the OWASP Top 10. The figure describes model behavior in a controlled benchmark, not the risk level of any specific production codebase.

2. Why is AI-generated Java code less secure than other languages? Veracode's testing found Java's security pass rate at just 29%, the worst of the four languages tested, against a high of 62% for Python. The likely cause is training data: models learn from decades of public Java code written before modern secure-coding patterns were standard, so they reproduce older, less secure idioms by default.

3. Does a high vulnerability rate in AI-generated code mean my application is at risk? Not by itself. A code weakness only becomes an operational risk once it is reachable and executed in production. Runtime evidence, not the presence of a flaw in the source, is what confirms whether a given AI-generated vulnerability is actually exploitable in your environment.

4. How does Kodem secure AI-generated code differently from a standard SAST scanner? Kodem's Runtime SAST correlates static findings, including those in AI-generated code, with runtime evidence to confirm whether the flagged function actually loads, executes, and is reachable, rather than treating every pattern match as equally urgent.

5. Will newer AI models fix the security gap in AI-generated code? The data so far says no. Veracode's testing shows AI security pass rates have held around 55% for two years even as syntax correctness rose past 95%, and larger models haven't meaningfully outperformed smaller ones on security, which points to a structural limitation rather than a temporary one.

References

Brombacher, F. (2026, March 24). Spring 2026 GenAI code security update: Despite claims, AI models are still failing security. Veracode. https://www.veracode.com/blog/spring-2026-genai-code-security/

OWASP Foundation. (2021). OWASP Top 10:2021. https://owasp.org/Top10/2021/