Veracode’s 2025 GenAI Code Security Report tested more than 100 large language models. They found 45% of AI-generated code contains security vulnerabilities. Nearly half of all code these AI tools produce is introducing security flaws into your codebase.
This isn’t theoretical. By mid-2025, teams using AI coding assistants are reporting 4× faster code generation but 10× more security findings. The velocity gains you’re celebrating today? They could be building tomorrow’s security nightmare.
But here’s the thing – banning AI tools entirely isn’t the answer. Your developers are already using them, officially or not. The question isn’t whether to use AI, it’s how to manage the security risks that come with it.
This security challenge is just one dimension of the broader IDE wars landscape, where competitive pressures and productivity promises are driving rapid AI coding tool adoption despite unresolved security concerns.
In this article we’re going to break down why AI models generate insecure code, which programming languages suffer the worst vulnerability rates, and what the 1.7× higher issue rate actually costs your team. More importantly, we’ll give you a practical framework for assessing your organisation’s exposure and deciding what to do about it.
What Does the 45 Percent Vulnerability Rate Actually Mean?
Veracode tested over 100 LLMs across Java, JavaScript, Python, and C#. They used 80 real-world coding tasks and ran the output through production-grade SAST tools, checking for the same security flaws that show up in human-written code.
The result? Only 55% of AI-generated code was secure. The other 45% contained at least one exploitable security weakness. We’re talking SQL injection (CWE-89), cryptographic failures (CWE-327), cross-site scripting (CWE-80), and log injection (CWE-117).
Not all vulnerabilities are critical. The distribution includes low, medium, high, and critical severity findings. But here’s your baseline: human-written code has roughly a 25-30% vulnerability rate in similar testing. That makes AI code about 1.5× worse than what your team produces manually.
CodeRabbit’s analysis of 470 pull requests backs this up. AI-generated PRs contain 1.7× more total issues and 2.74× more security-specific problems compared to human-only code.
Here’s what that looks like by vulnerability type:
SQL Injection (CWE-89): 80% pass rate means 20% of AI code had this vulnerability. That’s one in five code snippets potentially exposing your database to unauthorised access.
Cryptographic Failures (CWE-327): 86% pass rate. Models generated insecure cryptographic implementations 14% of the time. Hard-coded keys and deprecated algorithms that auditors love to flag.
Cross-Site Scripting (CWE-80): Models failed to generate secure code 14% of the time. Your web applications are wide open to script injection if you’re not catching these in review.
Log Injection (CWE-117): Models generated insecure code 12% of the time, enabling attackers to forge log entries and hide their tracks.
The 45% figure refers to individual code snippets, not entire applications. But remember – a single vulnerable function in a larger codebase is enough to create an exploitable weakness.
Why Do AI Models Generate Insecure Code?
AI models learn from publicly available code repositories. And here’s the problem – those repositories are full of vulnerabilities. Public GitHub repositories contain 40-50% vulnerable code patterns that LLMs inherit during training.
When a model encounters both secure and insecure implementations, it learns both as valid solutions. The training data includes good code, bad code, and ugly code, complete with insecure snippets and libraries containing CVEs.
But training data contamination is only part of it. The bigger issue? Context blindness.
AI tools generate code without deep understanding of your application’s security requirements, business logic, or system architecture. They can’t see your security-critical configuration files, secrets management systems, or service boundary implications.
Take input validation. Determining which variables contain user-controlled data requires sophisticated interprocedural analysis that current AI models just can’t perform. The model sees a database query and generates working code. Whether that query properly sanitises user input? That depends on context the model doesn’t have.
AI lacks local business logic and infers code patterns statistically, not semantically. It misses the rules of the system that senior engineers internalise. It doesn’t know that your authentication layer requires certain checks or that specific endpoints need extra validation.
General-purpose models are optimised for functionality, not security. There’s no security-aware fine-tuning in commercial models. Why? The compute cost is too high and there’s a lack of quality secure-code datasets.
The experts at Veracode put it simply: “AI models generate code that works functionally but lacks appropriate security controls.” Your tests pass. Your app runs. But the security controls that a senior developer would include by default? They’re missing.
Are Newer AI Models Generating More Secure Code?
Not really.
Veracode’s October 2025 update shows mixed results. GPT-5 Mini achieved a 72% security pass rate – the highest recorded. GPT-5 standard hit 70%. But the non-reasoning GPT-5-chat variant? Just 52%.
Here’s what’s more telling: the overall 45% vulnerability rate remained stable across GPT-4, GPT-5, Claude, and Gemini generations. Larger, newer models haven’t improved security significantly.
Look at the competitive landscape:
Claude Sonnet 4.5: 50% pass rate, down from Claude Sonnet 4’s 53%. That’s backwards progress.
Claude Opus 4.1: 49% pass rate, down from Claude Opus 4’s 50%. Another decline.
Google Gemini 2.5 Pro: 59% pass rate. Respectable, but not groundbreaking.
Google Gemini 2.5 Flash: 51% pass rate.
xAI Grok 4: 55% pass rate. Mid-pack performance.
Models from Anthropic, Google, Qwen, and xAI released between July and October 2025 showed no meaningful security improvements. Simply scaling models or updating training data isn’t enough to improve security outcomes.
Why? Because the training data problem persists. Training data scraped from the internet contains both secure and insecure code, and models learn both patterns equally well.
There is one bright spot. GPT-5’s reasoning models use internal reasoning before output – they function like an internal code review. Reasoning models averaged higher security pass rates than non-reasoning counterparts. The model evaluates multiple implementation options and filters out insecure patterns before committing to an answer.
Standard models generate code in a single forward pass based on probabilistic patterns. Reasoning models take more time but produce more secure results. That computational overhead might be worth it for security-sensitive code.
Don’t assume the latest model automatically generates more secure code. Test it. Measure it. And don’t skip the security review just because you upgraded to the newest AI assistant.
Understanding how these architectural choices shape the competitive landscape helps explain why security improvements lag behind feature development in the race for market dominance.
Which Programming Languages Have the Worst AI Vulnerability Rates?
Java is the worst performer. It has a 29% security pass rate. That translates to a 70%+ failure rate in AI-generated code.
Python performs best at 62% security pass rate. That’s still a 38% vulnerability rate, but it’s better than Java.
JavaScript sits in the middle at 57% pass rate. And C# comes in at 55% pass rate baseline, though newer models have improved this to around 60-65%.
Why does Java perform so badly? Java’s lower security performance likely reflects its longer history as a server-side language. The training data contains more examples predating modern security awareness. Enterprise legacy patterns dominate the corpus, and those patterns carry decades of accumulated security debt.
Java’s complex framework security models compound the problem. Spring Security, Jakarta EE, and other enterprise frameworks have sophisticated security architectures. AI models struggle to generate code that properly integrates with these frameworks because they lack the contextual understanding of how the pieces fit together.
JavaScript has its own challenges. The language runs in two very different contexts – client-side in browsers and server-side with Node.js. AI models have to contend with client-side issues like XSS and DOM manipulation vulnerabilities alongside server-side Node.js injection vulnerabilities.
Python’s relative advantage comes from cleaner training data drawn from scientific computing and data science. Python’s security patterns tend to be simpler and more standardised.
C# benefits from Microsoft’s security tooling influence. The .NET framework includes security guardrails that catch common mistakes. GPT-5 improved C# from a 45-50% baseline to around 60-65% pass rate, suggesting that targeted improvements are possible.
If you’re running a Java-heavy shop, you face higher AI code security risk than teams working in Python. That doesn’t mean you should abandon AI tools. It means your security scanning and code review processes need to be more rigorous when dealing with AI-generated Java code.
What Is the 1.7× Higher Issue Rate Costing Your Team?
CodeRabbit analysed 470 pull requests and found AI-generated PRs contain 1.7× more total issues overall. Security issues? 2.74× higher in AI-generated code. That’s a real shift in your team’s workload.
AI PRs show 1.4-1.7× more critical and major findings. Logic and correctness issues are 75% more common. And readability issues spike more than 3× in AI contributions.
Your review process wasn’t designed for this. Average review time increases 40-60% for AI-generated code due to larger diffs and subtle quality problems. Teams report 2-3× code review workload expansion when adopting AI tools without process changes.
Error handling and exception-path gaps are nearly 2× more common. Performance regressions? 8× more common in AI-authored PRs. Concurrency and dependency correctness see 2× increases.
Even the basics suffer. Formatting problems are 2.66× more common. AI introduces nearly 2× more naming inconsistencies. These aren’t just style issues. They make code harder to maintain and more likely to hide bugs.
By June 2025, AI-generated code introduced over 10,000 new security findings monthly in organisations Apiiro tracked. That’s a 10× increase from December 2024. And the trend is accelerating.
Here’s the false efficiency problem in stark terms: 2× longer review cycles and 3× more post-merge fixes offset initial velocity gains. Pull requests per author increased 20% year-over-year, but incidents per pull request increased 23.5%.
You’re not actually going faster. You’re shifting where the work happens.
The hidden costs pile up fast. AI-generated changes concentrate into fewer but larger pull requests. Each PR touches multiple files and services, diluting reviewer attention.
Your security team feels this acutely. They’re seeing substantial findings increases without corresponding increases in headcount or tooling budget. Something has to give. And usually it’s either review thoroughness or time to remediation.
How Serious Is the Security Debt Created by AI Code?
Security debt differs from technical debt in one key way: exploitability. Technical debt slows you down. Security debt opens you up to attack.
Veracode data shows vulnerabilities persist for more than one year in 30-40% of codebases. That’s not just delayed fixes. That’s compounding risk accumulating in production systems.
The cost multipliers are steep. Remediation costs increase 10-30× when fixes happen post-deployment versus during development. Fixing during development costs roughly $50 per vulnerability. Post-deployment fixes cost $500-5,000. Post-breach remediation? $50,000 or more per vulnerability.
Do the maths. If you’re introducing 10,000 new security findings monthly and your remediation capacity hasn’t scaled proportionally, you’re building a backlog that compounds every sprint.
The organisational damage extends beyond the vulnerability count. Unlike traditional coding, AI-generated vulnerabilities often lack clear ownership. Who’s responsible for fixing code that an AI wrote? The ambiguity complicates remediation efforts and leads to delays in addressing issues.
Your security team loses trust in the development process. Reviewers experience fatigue and start cutting corners. Over-reliance on AI tools risks creating developers who lack security awareness.
The compliance implications hit hard. Insecure AI-generated code processing personal data can trigger GDPR fines up to 20 million euros or 4% of global annual turnover. HIPAA civil penalties can reach $1.5 million per violation category per year. SOC 2 and ISO 42001 audits suddenly find more issues than you can remediate before the next audit cycle.
Average fix time is 2-8 hours per vulnerability depending on complexity. SQL injection and similar findings require 8-16 hours including testing and review. Multiply that by monthly findings and you’re looking at serious remediation work.
Can your team handle that load? Most can’t. So the debt accumulates. And with it, your attack surface grows.
Should You Ban AI Coding Tools Because of Security Risks?
No. Outright bans are counterproductive.
The solution is to use AI tools responsibly with appropriate security controls. Your organisation’s ability to implement effective security controls determines whether AI tool adoption succeeds or fails.
Here’s the practical reality: shadow AI tool usage is already widespread. Your developers are using ChatGPT, Claude, and other tools regardless of official policy. Bans drive usage underground where you have no visibility or control.
The better approach? Risk-based decision making. Assess exposure based on codebase criticality, compliance requirements, and industry vertical.
Some contexts justify strict restrictions. PCI-DSS scope code handling payment data. Healthcare systems processing PHI under HIPAA. Financial infrastructure where regulatory requirements are stringent. In these high-risk contexts, the cost of a breach far exceeds any productivity gains from AI tools.
Medium-risk scenarios like enterprise SaaS, internal tools, and non-critical systems can tolerate more permissive policies with appropriate guardrails. SAST scanning, enhanced code review, and security-focused prompts can mitigate most risks.
Low-risk contexts like prototypes, proof-of-concepts, and internal automation? Fine for unrestricted AI tool usage.
Industry context changes the calculation. Financial services and healthcare face higher regulatory risk than SaaS startups. A vulnerability that’s annoying for a consumer app could be catastrophic for a banking platform.
The competitive pressure matters too. Your competitors are likely using AI tools to move faster. And top developers expect modern tooling. Talent retention suffers when developers feel handicapped by outdated tools.
Organisations mandating AI coding assistants must simultaneously implement AI-driven application security governance. You can’t have the velocity without the controls.
With proper controls, AI code can meet production standards. Managed implementations using SAST, security-focused prompts, and enhanced review processes work. But unmanaged implementations create unacceptable exposure.
The ban-versus-manage decision comes down to honest assessment. Can you implement and maintain effective security controls? Do you have the SAST tooling, review capacity, and security team bandwidth? If yes, managed AI tool adoption makes sense. If no, either build that capacity or restrict usage until you can.
How to Assess Your Organisation’s AI Code Security Risk
Start with codebase criticality. Identify high-value targets, compliance-sensitive systems, and customer-facing infrastructure. Not all code carries equal risk. Your authentication system and payment processing require more scrutiny than an internal reporting tool.
Understanding current exposure involves identifying AI-generated code in your repositories. Developers often annotate AI usage in commit messages with patterns like “copilot,” “chatgpt,” or “ai-assisted.”
Run SAST tools specifically on AI-generated files. This gives you a baseline for comparison and helps identify whether AI code really is introducing more vulnerabilities than human code in your specific context.
Look for vulnerability patterns that commonly appear in AI-generated code. SQL Injection (CWE-89) involves missing PreparedStatement usage and concatenated user input. Cryptographic Failures (CWE-327) include deprecated algorithms and hard-coded encryption keys. Cross-Site Scripting (CWE-79) shows up as unsafe innerHTML operations and missing input sanitisation.
SAST detects 60-70% of AI vulnerabilities, missing architectural drift and context-blind logic errors. Combined SAST and human review catches 90-95% of issues. You need both.
Assess your language-specific exposure. Java teams face 70% vulnerability rates versus Python’s 38%. If you’re primarily a Java shop, your risk profile is higher than a Python-heavy organisation.
Evaluate current security posture. What’s your existing SAST and DAST coverage? How effective is your code review process? What’s your security team capacity?
Measure AI tool adoption honestly. Survey developers about shadow usage patterns. What tools are they using? How often? For what types of tasks? You need to understand what’s really happening.
Calculate review capacity. What’s your current PR throughput? What happens when that increases 20-50% due to AI acceleration? Do you have reviewer bandwidth to maintain quality with higher volume?
Assess compliance requirements. SOC 2 Type II demonstrates continuous operational effectiveness over 6-12 months. ISO/IEC 42001:2023 represents the first global standard for AI system governance. Your compliance obligations constrain your AI adoption options.
Quantify remediation capacity. Can your team handle a 10× monthly security findings increase? Calculate current backlog plus expected new findings multiplied by fix time per vulnerability.
Build a risk assessment matrix crossing codebase criticality with compliance requirements and language-specific vulnerability rates. High-criticality Java code under PCI-DSS scope? That’s your highest-risk category requiring maximum controls. Low-criticality Python prototypes with no compliance requirements? That’s lowest-risk where AI tools can run relatively unrestricted.
The assessment framework should be revisited quarterly. AI models change. Vulnerability patterns evolve. Your codebase grows.
What This Means for Your Security Strategy
The 45% vulnerability rate is real. But it’s a solvable problem, not an insurmountable barrier.
Three root causes drive the vulnerability rate: training data contamination, context blindness, and lack of security fine-tuning. None of these are going away soon. Newer models haven’t solved the security problem yet.
Language-specific variations matter. Java teams need heightened vigilance. Python teams have slightly better odds but still face substantial risk.
The 1.7× more issues represent real costs. Review workload expands. Security teams struggle to keep up. If you’re not planning for this workload increase, you’re setting yourself up for problems.
Security debt is the key long-term risk. Short-term velocity gains create long-term remediation burden. The $50 fix during development becomes a $5,000 fix post-deployment or a $50,000 fix post-breach.
Risk assessment is the first step. Understand your exposure before implementing controls. Use the framework in this article to categorise your code by risk level and apply appropriate controls to each category.
The productivity gains from AI coding tools are real. But they come with security costs that many organisations aren’t prepared to handle. The teams that succeed will be those that build security processes capable of handling the new reality—not those that pretend the risks don’t exist or ban the tools outright.
For comprehensive coverage of the security crisis in AI-generated code and how it fits into the broader competitive dynamics reshaping software development, explore our complete analysis of the IDE wars.
