Nearly half of AI-generated code has a vulnerability. Now what?

How common are security vulnerabilities in AI-generated code? The best measurement available says: present in nearly half of it. Veracode’s 2025 GenAI Code Security Report, which tested output from more than 100 models across 80 real-world coding tasks, found that 45 percent of samples introduced an OWASP Top 10 vulnerability. Not exotic flaws: the boring, well-understood classes we have been patching for twenty years.

If your team merges AI-generated code, and in 2026 it does, whatever the policy says, that number is your baseline until you build the process that changes it. The good news is that the process is known, cheap, and mostly a matter of deciding to run it.

What the numbers say about AI-generated code vulnerabilities

The details matter more than the headline. Java came out worst, with a 72 percent security failure rate; Python, C# and JavaScript ranged between 38 and 45 percent. By vulnerability class, the models failed to defend against cross-site scripting in 86 percent of relevant samples, and produced code open to log injection in 88 percent.

The finding that should reframe your planning: security performance did not improve with model size or recency. Newer, larger models wrote more syntactically correct code, and equally insecure code. Whatever curve you are hoping the next model release rides, this is not on it. Veracode’s own conclusion was that the problem is systemic rather than a scaling artifact, and nothing we have seen in production since contradicts them.

Why the model will not fix it for you

The causes are structural. Models learn from public code, and public code is full of unhashed passwords, string-built SQL, and unvalidated input; the training data votes for the vulnerability. The secure choice is usually invisible in the prompt: "store the user’s password" does not mention bcrypt, and the insecure implementation satisfies the request perfectly. And the vulnerable version passes the tests, because functional tests check behavior, not exploitability. The model is optimizing for everything your prompt and your checks measure. Security is in neither, unless you put it there.

That is the actual lesson of the 45 percent: it is not an argument against AI-generated code, it is a measurement of what happens when generation scales and verification does not.

The pipeline answer

The response that works is the same principle behind every guardrail we install in CI: one set of gates for every change, whoever or whatever authored it. Static analysis tuned to the OWASP classes the studies flag, dependency and secrets scanning on every change, and, critically, findings that fail the build rather than filing a ticket someone triages next quarter. A SAST report nobody must act on is decoration. At agent volume, decoration drowns.

Dependency checks deserve special attention because agents add packages fluently and optimistically, and typosquatted or abandoned packages are now a first-class supply chain risk. A new dependency should be a visible, reviewable event, not a line that scrolls past.

Give the agent the security context it lacks

Scanning catches what exists; context prevents it from existing. The teams with the lowest AI-vulnerability rates feed their standards to the agent up front: which crypto and hashing choices are canonical here, how authorization is checked, how input crosses trust boundaries, what never gets logged. Versioned in the repo as a security skill agents load on relevant tasks, that context turns "write the login handler" into "write the login handler the way this team does", and measurably fewer of the boring flaws ever reach review.

Review rules for sensitive paths

Machines first, then humans where humans matter. Authentication, payments, file upload, session handling, anything that parses external input: changes on those paths get a required, named human reviewer with security context, no self-approval, no time pressure, regardless of what wrote the code. Everywhere else, let the scanners and tiered review carry the load. Write the path list down in your AI usage policy so the rule survives the people who made it.

None of this is novel security engineering. It is the security engineering teams already knew they should do, made non-optional by volume. When we set up agentic engineering practices with a team, the security lane is usually a week of pipeline work and one skill file, and it converts the 45 percent from a headline into someone else’s problem. The vulnerability rate of the model is not your destiny. Your pipeline is.