45% of AI-generated code fails security tests (Veracode 2025). Here is why — Java 72%, XSS 86% — the named supply-chain attacks, and the controls that fix it.
45% of AI-generated code fails security tests. That figure comes from Veracode's 2025 GenAI Code Security Report, which ran the same security tasks across more than 100 large language models. Nearly half the time, the model shipped an exploitable flaw. Bigger, newer models did not do better.
If you are a CTO or engineering leader deciding how far to trust AI-written code, that one number is the whole conversation. Here is where it comes from, which languages and vulnerability classes fail worst, the named attacks that turned AI code into a breach, and the controls that close the gap.
Where the 45% figure comes from
Veracode's 2025 study is the largest controlled test of AI code security to date: standardised security tasks, run across 100+ models, scored on whether the generated code contained a known vulnerability. The headline result — a security flaw in 45% of tasks — held regardless of model size or release date. Newer, larger models were not measurably safer. The capability curve went up; the security curve did not.
This is not an isolated finding. NYU's "Asleep at the Keyboard?" audit of 1,689 GitHub Copilot programs against the CWE Top-25 found 40% contained vulnerabilities. Two independent studies, two different tools, the same order of magnitude: roughly two in five AI completions ship something exploitable when nobody checks.
The failure modes: which languages and vulnerabilities break
The 45% average hides the real problem — some languages and vulnerability classes fail far more often. Veracode's breakdown:
| Security test | AI-generated code failure rate | Source |
|---|---|---|
| Overall (100+ models) | 45% | Veracode 2025 |
| Java | 72% | Veracode 2025 |
| Cross-site scripting (XSS) | 86% | Veracode 2025 |
| Log injection | 88% | Veracode 2025 |
Read the bottom of that table twice. When asked to write code that handles untrusted input safely, models produced XSS-vulnerable output 86% of the time and log-injection-vulnerable output 88% of the time. These are not exotic bugs — they are OWASP staples with well-known fixes. The model knows the pattern; it just does not apply it unless the prompt and the pipeline force it to.
The confidence paradox: teams trust code they should not
The dangerous part is not the flaw rate. It is that developers do not see it. Snyk's 2025 research found that around 80% of developers believe AI generates more secure code than they write by hand — while 56.4% of the same developers frequently encounter security issues in AI output. Belief and evidence point in opposite directions.
Stanford researchers found the same effect in a controlled setting (CCS 2022): participants with an AI assistant produced more SQL-injection and crypto-misuse bugs than the control group — and were more confident their code was secure. The AI made them faster at being wrong and surer they were right. That combination is what turns a 45% flaw rate into shipped vulnerabilities: the reviewer's guard is down exactly when it should be up. And 80% of developers already bypass their organisation's AI code-security policies (Snyk 2025), so the guardrail that should catch it is often switched off.
When AI-generated code becomes the attack
Insecure output is one risk. The supply chain around AI coding tools is another — and in 2025 it stopped being theoretical.
s1ngularity / the Nx compromise (26 August 2025). Attackers used a stolen npm publish token to push malicious versions (20.9.0–21.8.0) of the popular Nx build tool. The post-install script did something new: it invoked the developer's own Claude, Gemini, and Q command-line agents with --dangerously-skip-permissions / --yolo and told them to scan the filesystem for secrets. Result: 2,349 secrets harvested from 1,079 developer machines, exfiltrated to a public GitHub repo. It was the first documented case of attackers weaponising AI coding agents as an exfiltration engine.
Disney / ComfyUI (2024). A Disney engineer installed ComfyUI_LLMVISION, a GitHub project that typosquatted an OpenAI dependency. The bundled infostealer sat quietly for five months, then drained his 1Password vault; the attacker pulled 1.1 TB of internal Slack data and 44 million messages. One unvetted clone for an AI side project became a company-wide breach.
Both attacks exploit the same weakness AI amplifies: slopsquatting. A USENIX 2025 study of 576,000 AI-generated code samples found that roughly 20% of the packages models recommend do not exist, and 43% of those hallucinated names recur across repeated queries. Attackers register the phantom name and wait for your pip install to run their code.
Why AI multiplies the risk instead of adding to it
Three forces compound. First, volume: AI-generated pull requests contain 10.83 issues each versus 6.45 for human PRs — about 1.7× more (CodeRabbit 2025) — and there are far more of them. Second, velocity: code arrives faster than human-speed review and overnight scans can keep up, so flaws merge before anyone looks. Third, bypass: with 80% of developers routing around security policy, the one control that could catch the 45% is optional in practice.
Regulators are closing in on this gap too — the EU AI Act's high-risk obligations become enforceable on 2 August 2026, and we cover what that means for engineering teams in a separate post. But you do not need a regulator to justify the fix. A 45% flaw rate is a reason on its own.
What to do about it: the Fortify controls
In AI-native development, security is not a gate at the end — it moves at the same speed as generation. This is the Fortify practice in the CRAFT Method, and it comes down to four controls:
- Scan at AI velocity. SAST, DAST, and SCA run on every pull request with sub-minute feedback, tuned with AI-specific rules (prompt injection, insecure defaults, hallucinated APIs). If your scan takes 30 minutes, the developer has already moved on. Block merges on critical findings — the 45% stat applies to your codebase too.
- Defend the supply chain. Enforce a dependency allowlist, block packages under 30 days old without manual approval, disable post-install scripts in CI (
npm install --ignore-scriptswould have stopped the Nx attack cold), and pin your MCP servers and IDE extensions. Treat every AI-suggestedinstallas untrusted until a registry-existence check clears it. - Track provenance. Tag AI-generated code at commit time and maintain SBOMs and AIBOMs. When a model advisory or a compromised package lands, provenance is what tells you — in minutes, not weeks — exactly which code is affected.
- Close the loop. Every confirmed vulnerability feeds back into your AI guardrails and anti-pattern files, so the same flaw is not regenerated next sprint. Detection without feedback is a treadmill.
None of this slows AI down. It makes AI velocity safe to keep. If you want to know where your organisation stands, start with the free CRAFT Method scorecard, or run the full Enterprise Diagnostic to score your Fortify practice against the five maturity archetypes.
Frequently asked questions
Is AI-generated code secure?
Not by default. Veracode's 2025 study found 45% of AI-generated code failed security tests across more than 100 models, rising to 72% for Java and 86% for cross-site scripting. AI code can be made secure, but only with scanning, supply-chain controls, and review calibrated for its speed and volume — not by trusting the model's output.
Why does AI write insecure code?
Models are trained to produce code that works, not code that is safe, and they reproduce the insecure patterns common in their training data. They also do not reason about your threat model or trust boundaries unless the prompt and pipeline force them to. The result is well-known vulnerabilities — XSS, injection, insecure defaults — reappearing at scale.
Do newer or larger AI models produce more secure code?
No. Veracode found the 45% failure rate held regardless of model size or release date — bigger, newer models were not measurably safer. Capability improved; security did not. Assuming the latest model has "fixed" the security problem is a common and expensive mistake.
How do I stop AI-generated vulnerabilities from reaching production?
Scan every pull request at AI velocity with SAST, DAST, and SCA; enforce dependency allowlists and disable post-install scripts to block supply-chain attacks like the Nx compromise; track provenance so you can trace affected code fast; and feed every confirmed vulnerability back into your AI guardrails. That is the Fortify practice in the CRAFT Method.