Why AI-Generated Code Fails Security Reviews 45% of the Time

My friend is a junior developer, roughly eight months into her first real job. She said the most enjoyable thing about her week was watching Copilot complete all of her tasks before she would even type the closing bracket. In other words, when she finished writing the login flow, it took her approximately twenty minutes. 

When she finished the payment form, lunch was already over. Additionally, the admin dashboard that her lead had budgeted to take three days to develop, my friend completed it in less than half of that time (an afternoon).

Six weeks after that, a pentester discovered that this same admin dashboard allowed any logged-in user (regardless of their role) to access an internal API and view every customer’s full billing history by simply changing a single number in the URL.

No one did anything stupid. The code ran. It passed QA. It appeared as though competent code was written in review because it read like competent code. However, it was not secure. To be honest, that's basically the reason why there has been a statistic floating around security communities for some time now: approximately 45% of the AI-generated code includes at least one known security vulnerability.

Where the 45% Actually Comes From

The best example of how to do this thoroughly is by using Veracode. Veracode tested over 100 LLMs on 80 programming tasks with four languages of code and compared their outputs for all of the well-known vulnerabilities, such as SQL injection, cross-site scripting, log injection, and weak cryptography, from OWASP. And unlike many other tests, they have continued to run these tests since 2025 and continue to update them.

Although the security failure headline result holds true, the resulting percentage that passed (approximately 55%) has remained essentially unchanged for two years. And here’s the surprising part that caught my attention – although the same models improved significantly on an ability to solve the actual programming problem itself within each successive reporting period, security-wise there was no improvement. 

That wasn’t something I thought would be the case when entering into this. I assumed that if there were improvements made to models, then there would be improvements in everything else too.

It’s Not Randomly Bad — It’s Bad at Specific Things

Why is a model so good at detecting certain types of vulnerabilities but so consistently poor at identifying other vulnerability types? It is simply because the model doesn’t think “Is this secure?” when it generates its output. 

Instead, the model makes predictions on the probability that the next possible token will be generated, considering every single thing it has been trained on. That includes all public sources such as GitHub repositories, tutorials, and even older Stack Overflow questions that are likely from developers who had the same goal as you: “just get it done.” Its focus is not on creating an airtight solution. The model is not generating new ways to create flaws or bad coding practices. It’s merely adopting our own.

“It Works” Versus “It’s Safe”

Beyond the statistical headline number — and I've included one of those below — lies another important takeaway from some very recent research. An additional measure of performance also comes from testing an "agentic" configuration (such as the model itself performing a task versus simply completing a sentence or two). Of what the model created, about 61% of it worked. However, about 10.5% of what the model created could be exploited.

Take time to absorb this difference. The model typically knew the what, but nearly always did not know how to create something that would prevent exploitation. This aligns perfectly with how most of these types of reviews occur. Do we see evidence of code passing the test? Does the demo work? Is the pull request looking nice and clean? These are all things a model is going to check for during training. No team is asking their models, "Can this be broken?" And so they have no reason to find out.

What's More Worrying Than the Stat

There is a study that has compared developers who are coding with the help of AI with those who are coding without the help of AI. The group that used the AI wrote less secure code. However, they felt their own work was even more secure.

Well, no, it's not a technical issue when you consider it. It's a problem of trust. When a tool gives you something that is clean, well-formatted, and looks like it was done by someone who knows their way around, it's easy to forget to ask if the person (or model) who did it really knew what they were doing. It looks just like that.

Now pile on top of speed. Teams using AI assistants are shipping commits three to four times faster than before, based on data from some large enterprise engineering orgs. Great, except that the same data indicated that the number of security findings was increasing at about 10 times the rate of commits. Ten times as much code is being reviewed as ever, but with the same level of scrutiny.

Is This the New Norm?

There are a few things that move the needle — and none of them are complicated.

It's a real difference to request security explicitly in the prompt. In one test, a model was able to produce 6 out of 10 secure outputs on a plain prompt, but 10 out of 10 when prompted to produce secure code. It was there already, and it was a capability. It wasn't requested. Most of us are calling for "make this work" rather than "make this hard to break.

The models that go through a problem step-by-step — reasoning models — do noticeably better. Some testing reports a pass rate of 70–72% compared to the baseline of about 55%. Better, for sure. Still indicates that about 30% of the outputs have a genuine defect.

There is nothing like a second pair of eyes when it's not the second pair that wrote the code. It could be a human reviewer, or it could be a static analysis tool that runs on all PRs that are reviewed by AI — the point is the model that wrote the bug is structurally incapable of detecting its own bug. The blind spot was a result of training. It is not a typing error that it can detect and correct.

Where This Actually Leaves Us

Don't get rid of the AI tools, though. They're not leaving, and the productivity boost is actually quite real — a massive percentage of the code being committed to GitHub is being written with AI in some way.

However, the two assertions “it compiles” and “it is safe to put in front of paying customers” proved to be two separate ones, and at present, only one is checked by default. The 45% isn't so much a cause for concern for coding tools in general, but for AI coding tools in particular. It's a good excuse to not skip the review step, particularly in a place where it's clearly getting it wrong, like auth, payments, user data, or permissions.

My friend who has the admin dashboard is not careless. She had trusted it with a hundred little things, and it had gained her trust. The dashboard was the hundred-and-first, the one where it works and it's secure, no longer meant the same thing.