AI writes half of all code and fails security tests 44% of the time. See the failure profile, why capability gains have not helped, and what review must change.
AI writes roughly half of all committed code and fails security tests about 44% of the time. Model capability has improved sharply since 2024. Security performance has not. And the developers reviewing that output are measurably worse at catching flaws when AI produced them.
Veracode’s 2026 GenAI Code Security Report is the largest longitudinal test available, covering more than 100 models across four testing snapshots.
The headline number is stable and unflattering. The average security pass rate sits at 56%, virtually unchanged since the previous year. Given no security-specific prompting, models fail nearly 44% of the time.
Stability is the finding, not the percentage. Coding benchmarks climbed steadily across the same period while the security pass rate stayed flat. Models got better at writing code that works without getting better at writing code that is safe.
Academic work agrees. Pearce and colleagues found roughly 40% of Copilot-generated programs contained vulnerabilities across 1,689 programs, and a systematic review by Negri-Ribalta and colleagues across 19 studies reported high-level agreement that AI models do not produce safe code.
One contrast in the Veracode data explains why this keeps surprising engineering teams.
Models generate compilable code at a syntax pass rate close to 100%. On security, they fail nearly 44% of the time. Fluency and safety have separated completely.
That matters because fluency is what a reviewer sees. Code that compiles, runs, reads cleanly, and follows house conventions carries every signal a developer uses to judge quality. The vulnerability is not visible in any of them.
So the usual quality heuristics have stopped working as security heuristics. A senior developer scanning for the things that used to indicate sloppiness will find nothing wrong, because nothing about the output is sloppy.
Discover how Threatcop protects your workforce from modern cyber threats.
Failure is concentrated rather than uniform, which makes it targetable.
| Weakness | How often models fail |
|---|---|
| Log injection (CWE-117) | 88% of samples vulnerable |
| Cross-site scripting (CWE-80) | 86% of samples vulnerable |
| SQL injection (CWE-89) | 20% of samples vulnerable |
| Insecure cryptography (CWE-327) | 14% of samples vulnerable |
Read the top two rows carefully. These are OWASP Top 10 staples, not exotic edge cases, and models fail them most of the time.
Language matters too. Java performed worst, exceeding a 70% failure rate for secure code generation. Wider context on the shift appears in where AI is changing the threat picture.
The pattern makes sense once you see it. SQL injection has one canonical fix that appears everywhere in training data, so models reproduce it. Cross-site scripting requires knowing which variable reaches which context, which needs application knowledge the model does not have.
Volume is the part that turns a quality problem into a governance problem.
The Cloud Security Alliance’s research note on AI-generated code reports empirical work across Fortune 50 enterprises finding that AI-assisted developers produce commits at three to four times the rate of their peers, while introducing security findings at ten times the rate.
Those two multipliers do not cancel. Output rose fourfold and findings rose tenfold, so defect density went up alongside volume.
Veracode’s 2026 State of Software Security puts the consequence in balance-sheet terms: security debt now affects 82% of organisations, critical security debt affects 60%, and high-risk vulnerabilities rose 36% year over year.
Meanwhile, Verizon’s 2026 Data Breach Investigations Report found software vulnerabilities have become the top breach entry point at 31%, overtaking stolen credentials. The debt is being collected.
A tempting conclusion runs like this. Humans were never good at secure coding; AI now writes most of it, so the effort belongs on making the models safer and human training is obsolete.
The first half is defensible. The second half is where it breaks.
Governance questions raised by that pace appear in the governance layer beneath automation. Models will improve, and security-specific prompting does raise pass rates. Even so, four years of capability gains produced no movement in the security pass rate, so treating the next model release as the fix has a poor track record.
More importantly, the model is not the last line. A human approves every commit. That reviewer is the control, and the evidence on how that control is performing is the most alarming part of this literature.
Perry and colleagues ran a user study comparing developers working with and without an AI assistant. Two findings matter, and the second matters more.
Participants using AI assistants wrote significantly less secure code. That much is expected.
They also exhibited what the researchers called a false sense of security, frequently rating their insecure solutions as secure. Confidence moved in the opposite direction from correctness.
A systematic analysis of this literature places that finding alongside related work showing AI-generated code lacks defensive programming constructs and contains subtly incorrect implementations of security-critical algorithms.
The implication for review is direct. A reviewer is not a neutral backstop who happens to be checking AI output. Working alongside AI has changed how carefully they check, in the wrong direction, without them noticing.
Secure coding training has not become obsolete. Its subject has changed.
The old curriculum taught developers to write secure code. The new one has to teach them to review code they did not write, produced by a system they are inclined to trust, in volumes that discourage close reading.
Four things belong in that training:
Threatcop’s TLMS delivers this as role-specific content rather than a shared module, so developers get the review scenarios while other functions get theirs. Programme design sits in training built around what each team does.
Training is one layer. Six controls do not depend on anyone’s attention holding.
Item 6 is the one almost nobody does, and it is what turns this from a debate into a measurement. Supply chain exposure in the same pipeline appears in when a supplier failure becomes your incident.
Lines of code shipped is the wrong headline metric in an AI-assisted pipeline, because it is the number AI moves most and security least.
The first is the honest one. If AI-assisted commits show a higher finding rate, you have the CSA result in your own data and a case for changing the review process.
Split your last quarter’s security findings by whether the commit was AI-assisted, then compare findings per thousand lines. Most teams have never run that comparison, and it settles the question for your codebase rather than in the abstract.
If the AI-assisted rate is higher, the Cloud Security Alliance finding is reproducing in your environment, and the answer is review process rather than model choice.
Then train the people doing the reviewing on the confidence effect specifically, because a reviewer who knows their judgment degrades with AI assistance reviews differently from one who does not.
Veracode’s 2026 GenAI Code Security Report, covering more than 100 models across four testing snapshots, found an average security pass rate of 56%. Given no security-specific prompting, models introduce a known vulnerability in roughly 44% of generation tasks. Earlier academic work found around 40% of Copilot-generated programs contained vulnerabilities.
Not meaningfully. Veracode’s tracking across four snapshots shows the security pass rate virtually unchanged year over year, even as coding capability benchmarks improved substantially over the same period. Models became better at producing working code without becoming better at producing safe code.
Failure concentrates in context-dependent weaknesses. Testing found 88% of samples vulnerable to log injection and 86% vulnerable to cross-site scripting, against 20% for SQL injection and 14% for insecure cryptography. Java performed worst by language, exceeding a 70% failure rate for secure generation.
Less reliably than expected. A user study by Perry and colleagues found participants using AI assistants wrote significantly less secure code while exhibiting a false sense of security, often rating insecure solutions as secure. Confidence rose while correctness fell, which means review quality degrades precisely where more scrutiny is needed.
Yes, with different content. Since AI produces most code and a human still approves every commit, the reviewer is the control point. Training should cover the documented confidence effect, the weakness classes models fail most often, flaws requiring application context the model lacks, and prompting explicitly for security rather than assuming it.
Anjali is the Cybersecurity Manager at Kratikal, leading a team focused on strengthening security through rigorous vulnerability assessments and penetration testing. With expertise across web, network, and cloud environments, she drives strategies to safeguard clients’ critical assets while mentoring her team and staying ahead of escalating cyber threats.
One vendor's ransomware stopped four European airports. See what was actually confirmed, why insurance is priced into the attack,...
Over 90% of employees who took unsafe actions knew the risk. See why the awareness-action gap is a design...
AI-to-AI communication already runs on MCP and A2A, and neither mandates an audit trail. See how each fails, and...
