Veracode's GenAI Code Security Report landed this month, and the headline number is stark: 45% of AI-generated code contains security vulnerabilities aligned with the OWASP Top 10. Java showed failure rates above 70%.
That's not 45% of adversarially prompted code. Not 45% of code generated by obscure models. Forty-five percent of the AI-generated code analyzed in a systematic security study contains vulnerabilities that are well-understood, well-documented, and well-represented in every security professional's threat framework.
OWASP Top 10 vulnerabilities aren't exotic zero-days. They're injection flaws, broken authentication, sensitive data exposure, XML external entity processing, broken access control — the foundational security failures that every security-conscious organization trains its developers to avoid. And AI is generating code containing these vulnerabilities at a rate of nearly one in two.
What the Numbers Actually Mean
Let's put 45% in operational context.
If your engineering team uses AI coding tools — and based on the data, 84% of development teams do — roughly half of the AI-generated code suggestions your team receives contain security vulnerabilities. Not subtle, novel vulnerabilities that require sophisticated analysis to detect. The OWASP Top 10. The vulnerabilities that automated security scanners have been built to detect for over a decade.
The Java finding is worse. Over 70% failure rates mean that AI-generated Java code is more likely to contain security vulnerabilities than not. For organizations running enterprise Java applications — which describes much of the financial services, healthcare, and government sectors — this number represents an active threat to their security posture, introduced through the very tools they adopted to improve productivity.
And here's the compounding factor: these vulnerabilities are being generated by tools that developers increasingly trust to handle complex implementation tasks. When a developer asks an AI coding tool to implement authentication, the tool generates code that looks correct — proper structure, reasonable logic, appropriate patterns. The vulnerability isn't visible in the code's surface appearance. It's in the subtle implementation details: a missing input validation, an incorrect token handling pattern, an overly permissive access control configuration.
The developer, who adopted the AI tool precisely because it generates code faster than they can write it manually, is unlikely to conduct the detailed security review necessary to catch these issues. They accepted the code because it looked right. The vulnerability shipped to production because looking right and being secure are different things.
Why AI Models Generate Insecure Code
The root cause isn't a mystery once you understand how language models generate code. Models are trained on vast corpora of existing code — and existing code is full of security vulnerabilities. The internet, GitHub repositories, Stack Overflow answers, and tutorial sites collectively represent the training data for AI coding models, and that training data reflects the reality that most publicly available code was not written by security experts.
When a model learns to generate code from this corpus, it learns the patterns that appear most frequently. And the patterns that appear most frequently are not the most secure patterns — they're the most common patterns, which often reflect the quickest way to make something work rather than the most secure way to make something work.
This is a structural problem, not a tuning problem. You can fine-tune models on secure coding examples, and that helps at the margins. But the fundamental tension between "code that works" and "code that's secure" is deeply embedded in the training data. Secure code often requires additional steps — input validation, output encoding, proper error handling, parameterized queries — that add complexity without adding visible functionality. Models optimized to generate code that satisfies the developer's immediate request will tend to skip these steps unless specifically prompted to include them.
And this connects directly to the guardrail bypass problem we documented in May with the FlipAttack research. Just as prompt-level guardrails can be bypassed because they operate on surface patterns rather than deep understanding, code security properties can be missed because they require understanding the security context of code — not just its syntactic correctness.
The CISO's New Threat Vector
For Chief Information Security Officers, the Veracode findings introduce a new category of threat that doesn't fit neatly into existing security frameworks.
Traditional application security threats come from outside — attackers exploiting vulnerabilities in deployed applications. The response is well-established: vulnerability scanning, penetration testing, security code review, and patch management. These are reactive measures that catch vulnerabilities after they're introduced.
AI-generated code vulnerabilities come from inside — from the development tools that your own team uses every day. The threat isn't an attacker exploiting a vulnerability; it's the development process generating vulnerabilities at industrial scale. When 46% of code is AI-generated — as GitHub's own data would show later this month — and 45% of AI-generated code contains security vulnerabilities, you have a math problem that no amount of perimeter security can solve.
The conventional application security scanning pipeline was designed for human-paced code production. Developers write a feature over several days, and the security scan runs in the CI/CD pipeline before deployment. The scanner might find a handful of issues per feature branch, and the development team addresses them.
When AI generates code at machine speed, the volume of code entering the pipeline increases dramatically. More code means more potential vulnerabilities, which means more scanner findings, which means either more remediation work or more findings being deprioritized and shipped. The pipeline was designed for a trickle. It's now receiving a flood.
The Verification Layer That Security Scanning Misses
Security scanning tools catch known vulnerability patterns in code that has already been written. They're essential, but they operate after the fact — they find problems, not prevent them.
What's missing is a verification layer that operates before or during code generation — checking AI output against security specifications before the code enters the codebase. This is the difference between catching a defect in quality inspection and preventing it through process control. Both matter, but prevention is more efficient than detection.
For AI-generated code, prevention means defining security requirements as machine-readable specifications that AI output must satisfy. Instead of scanning generated code for known vulnerability patterns after the fact, you verify that the generated code implements required security measures during the generation and review process. Does the authentication implementation include rate limiting? Does the data access layer use parameterized queries? Does the API endpoint validate input types and ranges?
These aren't questions that require sophisticated security analysis. They're specification checks — verifying that required elements are present. The same approach that prevents functional defects (specification-driven verification) also prevents security defects, because security requirements are requirements.
At CleanAim®, our 11-dimension verification audit includes security-relevant checks as part of the same automated verification that checks functional correctness. When AI-generated code misses a security requirement, it's caught in the same pass that catches missing tests or spec violations — before the code reaches the repository, not after.
The Java Problem and Language-Specific Risk
The Java finding — 70%+ failure rates — deserves specific attention because of what it reveals about language-specific risk.
Java's enterprise ecosystem includes complex frameworks (Spring, Jakarta EE, Hibernate) with security-relevant configuration that is notoriously difficult to get right even for experienced developers. The combination of framework complexity and security sensitivity creates a particularly challenging environment for AI code generation. The model needs to understand not just Java syntax but the security implications of specific framework configurations — and the training data is full of examples where those configurations are insecure.
This suggests that AI code generation risk isn't uniform across languages and frameworks. Languages with simpler security models and less configuration complexity may have lower vulnerability rates. Languages with complex frameworks and extensive security-relevant configuration — Java, C#, PHP — may have higher rates.
For security teams, this means that the level of verification required for AI-generated code should vary by language and framework. A blanket policy of "scan everything equally" may under-invest in scanning the most risky code and over-invest in scanning lower-risk code.
What Needs to Change
The Veracode findings demand a response at three levels.
At the tool level, AI coding tool vendors need to invest in security-aware code generation. This means training on secure coding corpora, building security checks into the generation process, and being transparent about the security characteristics of generated code. The fact that no major AI coding tool publishes its vulnerability rates for generated code — despite having the telemetry to compute them — suggests this isn't a priority yet.
At the process level, engineering organizations need to adapt their security processes for AI-generated code. This means higher scrutiny for AI-generated code in security-sensitive contexts, language-specific verification requirements, and automated security specification checks as part of the AI code acceptance pipeline.
At the infrastructure level, the industry needs verification infrastructure that treats security as a first-class verification dimension — not an afterthought scanned at the end of the pipeline, but a specification checked during code acceptance. When security requirements are machine-readable and verification is automated, the 45% vulnerability rate becomes catchable. When security is left to post-hoc scanning, the volume of AI-generated code overwhelms the scanning capacity.
Looking Ahead
The Veracode study is the first large-scale, systematic analysis of AI-generated code security. It won't be the last, and subsequent studies will likely produce similarly concerning numbers until the underlying causes are addressed.
For CISOs, the action item is immediate: understand how much of your codebase is AI-generated, apply appropriate verification intensity to that code, and invest in specification-driven security verification that operates at the speed of AI code generation.
Forty-five percent is the number. The response is infrastructure, not hope.