Veracode: AI-generated code still fails 44% of security tasks, flat for a second year

Large language models now produce code that almost always runs — and nearly half the time, code that should not ship. Veracode's 2026 GenAI Code Security Report puts the average security pass rate for AI-generated code at 56%, meaning roughly 44% of tasks failed, a result essentially unchanged from the 2025 edition. The findings were summarised in a November 2026 dev.to write-up, originally published on shipfastdev.com.

The contrast between those two numbers is the core problem. According to the dev.to analysis, the tested code compiled close to 100% of the time. Functional correctness keeps improving; security does not.

What Veracode measured

Veracode's 2025 report handed 80 curated coding tasks to more than 100 large language models. When both a secure and an insecure implementation were available, models chose the insecure one 45% of the time. Java was the riskiest language, failing security checks in more than 70% of tasks, while Python, C# and JavaScript fell between 38% and 45%. Models failed to defend against cross-site scripting in 86% of cases and log injection in 88%. Larger models did not do meaningfully better than smaller ones.

The 2026 edition found no progress. The best model on the summer 2026 leaderboard reached a 68% pass rate, which still means failing close to one security task in three. Python code passed 63% of the time against 30% for Java. Coding-specialised models (51%) were on par with general-purpose ones (52%), and model size again made no clear difference, although reasoning models kept a modest edge at 56% versus 51%.

Independent research points the same way

Academic studies agree. "Asleep at the Keyboard?", presented at the IEEE Symposium on Security and Privacy in 2022, generated 1,689 programs across 89 security-relevant scenarios with GitHub Copilot and found roughly 40% of them vulnerable. A user study published at ACM CCS 2023 found that participants working with an AI assistant wrote significantly less secure code than those without — and were more likely to believe their code was secure.

A USENIX Security 2025 paper analysed 576,000 code samples from 16 models and found that 5.2% of packages suggested by commercial models, and 21.7% of those suggested by open-source models, did not exist, with 205,474 unique invented package names. An attacker can register a malicious package under a name a model tends to hallucinate, turning an unchecked install into a direct compromise path.

Why the failure rate is not falling

Security usually depends on context the model does not have: which input comes from an untrusted user, who may see which record, which secrets exist in the environment. The dev.to article notes that cross-site scripting, which requires knowing where data will be displayed, was among the worst results in the 2025 tests. The model delivers what was asked; whether it is safe depends on what was left unsaid.

The recurring failure patterns include:

• Untrusted input reaching output or queries: cross-site scripting, SQL injection, log injection.
• Missing authorisation checks, such as an endpoint that verifies a user is logged in but not that the record belongs to them.
• Secrets pasted into source files or shipped in front-end bundles.
• Invented or outdated dependencies.
• Insecure defaults: permissive CORS, debug mode on, verbose errors in production.
• Weak cryptography or hand-rolled authentication instead of framework primitives.

At the organisational level, Google's 2025 DORA report found AI adoption is linked to higher delivery throughput but still shows a negative relationship with delivery stability. Its explanation applies directly to security: without strong automated testing and fast feedback loops, more change volume produces more incidents.

What the write-up recommends

The dev.to piece argues the answer is not to ban AI tools but to hold their output to the standard of any unvetted external contribution: review, scan and test before production. Its checklist calls for a human reviewing every AI-generated change line by line, authorisation checks (not just authentication) on every endpoint, server-side input validation with framework-level output escaping, parameterised queries, verification that new packages exist and are maintained, automated dependency audits and secret scanning, static analysis in CI on every pull request, tests covering login, permission and payment flows, hardened production defaults, keeping AI agents away from production credentials, and clear ownership of security decisions.

Why it matters

AI-written code has become a default part of development workflows, and Veracode's data shows its security performance flatlined between the 2025 and 2026 reports even as the code got better at compiling. Waiting for the next model generation is therefore not a mitigation strategy, and Java teams in particular are working from a 30% pass rate. The practical consequence is that long-standing best practices — human review, static analysis, dependency audits, secret scanning and authorisation tests — now determine whether teams ship faster or simply ship vulnerabilities faster. The CCS 2023 finding that AI assistance breeds overconfidence makes skipping those gates especially tempting, which is exactly why they should run automatically in CI rather than depend on developer discipline.