According to DX Research’s Q1 2026 analysis of 500+ organisations, 27% of all production code is now AI-generated. More than one in four lines your team ships came out of GitHub Copilot, Cursor, or something similar. And your SAST tools were not built for any of it.
The problem is structural. Veracode’s GenAI Code Security Report found 45% of AI-generated code contains security vulnerabilities — and traditional scanning misses a big chunk of them. Not because the tools are misconfigured. Because the vulnerabilities don’t look like anything the tools were built to find.
What follows is a breakdown of the broader AppSec shift now underway — covered comprehensively in our securing the AI-generated code pipeline overview — the four SAST failure modes, three named attack patterns, the vibe coding problem, and a self-assessment checklist. The data is from Veracode, DX Research, ZeroPath, and RSAC 2026. No vendor pitches.
Why has AI-generated code become the #1 AppSec blind spot?
At 27% of production, AI-generated code has gone from novelty to a fact of life — and any systematic gap in how that code gets scanned is an organisation-wide exposure. Veracode tested over 100 LLMs and found 45% of AI-generated code contains at least one security flaw. CSA and Endor Labs arrived at 62% using a different methodology. CVEs formally attributed to AI-generated code jumped from 6 in January 2026 to 35 in March 2026. That’s not a blip.
The mismatch is structural. SAST was built around human coding conventions: consistent naming, traceable intent, coherent access control logic. AI output often has none of those things. Veracode calls the downstream consequence “vulnpocalypse” — as AI code volume scales, undetected vulnerabilities pile up faster than security teams can work through them. RSAC 2026 confirmed these findings as a genuine industry inflection point, not vendor-manufactured alarm.
Where do traditional SAST tools actually break on AI output?
SAST works by matching code against a library of known vulnerability signatures. AI-generated code breaks that in four specific ways.
Training data reproduction. LLMs reproduce insecure patterns from pre-2022 GitHub and Stack Overflow training data. The pattern looks syntactically valid, matches no known CVE signature, and still carries the same vulnerability logic.
Hallucinated dependency blindness. When an LLM invents a package name that doesn’t exist in any registry, SAST has no rule to flag it. The package name is novel, not malicious in form. The tool just moves on.
Context-dependent access control failures. AI models generate authorisation logic that looks locally correct but is inconsistent across a codebase. SAST analyses files in isolation — it can’t evaluate whether access control is enforced consistently at the application level.
Prompt-injection sinks. Code generated to handle user input may route that input to LLM calls without sanitisation. SAST rules exist for SQL injection and XSS sinks. Rules for LLM prompt-injection sinks largely don’t — and prompt injection has been the number one vulnerability on the OWASP Top 10 for LLM Applications since 2025.
ZeroPath’s vm2 CVE analysis demonstrates SAST miss rates in AI-generated code that simply don’t appear in human-written equivalents. DAST and SCA partially compensate, but they cover different ground — neither closes the full gap without deliberate toolchain design.
What are hallucinated dependencies — and what is slopsquatting?
Hallucinated dependencies are non-existent packages that LLMs confidently recommend during code generation. A 2025 USENIX study analysed 576,000 code samples across 16 LLMs and found nearly 20% of recommended packages did not exist — and 43% of those hallucinated names repeat consistently across queries.
That repeatability is what makes slopsquatting tractable as an attack. Adversaries register the npm, PyPI, or other registry names that AI tools are known to hallucinate, then load those packages with malicious payloads. In January 2026, a hallucinated npm package called react-codeshift spread through 237 repositories via AI-generated agent skill files with nobody deliberately planting it.
SAST can’t detect this because the vulnerability sits at the dependency resolution layer. SCA is the right tool category — but only if SCA tools are updated to flag packages absent from known-good registries, not just known-bad ones. The risk compounds further when autonomous agents commit this code to CI/CD pipelines without human review, removing the last manual checkpoint that might catch an unfamiliar package name.
Why is AI-generated Java code failing at almost 72%?
Veracode’s report found Java was the worst performer, with a 72% security failure rate. The Spring 2026 update confirms this: Java’s security pass rate sits at 29%, compared to Python at 62%, C# at 58%, and JavaScript at 57%.
Enterprise Java uses complex access control logic that AI models generate inconsistently. Java’s XML and serialisation handling has historically been one of the richest sources of injection and deserialisation vulnerabilities, and AI models reproduce those patterns with confidence. Scaling up the model doesn’t help either: security performance clusters around the same 55% mark whether you’re using 20B or 400B parameter models. Syntax pass rates have climbed to 95%, but security pass rates haven’t moved.
If your team is shipping AI-generated Java at scale, you’re operating with a higher undetected vulnerability exposure than the headline 45% figure suggests.
How does the Rules File Backdoor attack bypass review?
The Rules File Backdoor is an attack where adversarial instructions are embedded into AI coding assistant configuration files — Cursor’s .cursorrules files or GitHub Copilot instruction files. When a developer uses a compromised rules file, the AI tool silently introduces backdoors, weakens authentication logic, or adds covert data exfiltration paths — all while generating code that looks functionally correct to anyone reviewing it.
The bypass is clean. The malicious instruction is in the configuration file. The generated code looks fine. SAST scans the code, not the configuration layer sitting above it. Pillar Security researchers demonstrated this attack in practice. Cursor IDE CVE-2025-54135 allowed chaining an indirect prompt injection to trigger remote code execution with no user interaction at all.
This is not a code-layer problem. The response is toolchain governance: controlling which rules files developers can use, reviewing shared rules files, and treating AI coding tool configuration the same way you’d govern third-party plugins.
What does vibe coding do to your tooling’s signal-to-noise?
Vibe coding — coined by Andrej Karpathy in February 2025 — describes delegating most code writing to AI assistants with minimal manual review. It grew 340% year over year in enterprise environments, well beyond the rapid-ideation use case Karpathy had in mind.
The AppSec problem is that vibe coding removes the human review layer that has historically been a compensating control for SAST blind spots. More vulnerabilities enter the codebase. SAST alert volume goes up with a shifted true-positive ratio, because AI-generated code produces patterns SAST rules were never tuned for. AI-assisted commits expose secrets at more than twice the rate of human-only commits — 3.2% versus 1.5%. If vibe coding is the team norm, your AppSec tooling is operating out of specification.
How should you audit your current AppSec coverage?
Before making tooling decisions, assess where your current programme has coverage gaps specific to AI-generated code. Only 18% of organisations have established approved AI tool lists. You need your own numbers first.
Six dimensions to assess:
-
Code origin mapping. What percentage of production code is AI-generated? DX’s 27% is the industry benchmark. Which tools generate it?
-
SAST rule currency. When were your SAST rules last updated? Do they include rules for prompt-injection sinks and AI-specific vulnerability classes? Most commercial SAST tools haven’t shipped these yet.
-
Dependency verification coverage. Is SCA running on every pull request, flagging packages absent from known-good registry histories — not just known-bad lists? Catching vulnerabilities before code merges is cheaper than finding them in production.
-
Access control consistency testing. Does your testing programme include dynamic checks — DAST or manual testing — for authorisation logic across AI-generated API endpoints? SAST alone is not enough.
-
Rules file governance. Do you have a policy governing which AI coding assistant configuration files developers can use? These attack surfaces have no analogue in traditional SDLC guidance.
-
Vibe coding visibility. Do you have tooling or policy visibility into whether developers are reviewing AI-generated code before committing? Only 38% of organisations use AI to support code review in pull requests.
Identify the gaps before deciding where to invest. OWASP categories give you a useful framework for prioritising what you find. For a structured assessment of the tools now emerging to address these gaps — from AI-aware SAST platforms to ASPM consolidation — see our vendor comparison. For a complete picture of the broader AppSec shift, including the organisational and compliance dimensions, see our securing the AI-generated code pipeline overview.
FAQ
Does AI-generated code introduce vulnerabilities at a higher rate than human-written code?
Yes. Veracode’s GenAI Code Security Report found 45% of AI-generated code contains at least one vulnerability, with Java reaching 72%. CSA/Endor Labs arrived at 62% via a different methodology. AI-generated vulnerabilities also skew toward classes that SAST is poorly positioned to detect.
What is the difference between AI-assisted coding security and AI-generated code security?
AI-assisted coding security is about securing the tools themselves. AI-generated code security is about the vulnerabilities in their output. Both need attention — toolchain governance for the former, upgraded scanning and testing for the latter.
What is slopsquatting, and how is it different from typosquatting?
Slopsquatting exploits AI hallucinations: attackers register package names that AI coding assistants commonly recommend but that don’t exist, then load them with malware. Typosquatting requires guessing developer typos. Slopsquatting is more tractable because AI tools hallucinate the same names reproducibly — 43% of hallucinated names repeat consistently.
Can SAST tools be updated to handle AI-generated code better?
Yes, but the updates go beyond adding rules. Hallucinated dependency risks require SCA integration and registry verification. Context-dependent access control failures require DAST. Rules File Backdoor attacks require toolchain governance. The four core failure modes need a layered toolset, not an upgraded single tool.
What is the Rules File Backdoor attack?
Adversarial instructions inserted into AI coding assistant configuration files — Cursor .cursorrules or GitHub Copilot instruction files — cause the AI tool to silently introduce backdoors or weaken security controls while producing code that looks correct to reviewers. Full explanation with specific CVEs is in the section above.
Why can’t my SAST scanner find bugs in AI-written code?
SAST uses pattern matching against known vulnerability signatures. AI-generated vulnerabilities don’t match those patterns — the code reproduces insecure training-data logic that never matched a CVE, invents package names SAST has no rule for, and produces prompt-injection sinks that SAST rules haven’t been written to detect.
Is vibe coding safe to use in a production engineering environment?
Vibe coding removes the human compensating controls that catch SAST-evasive vulnerabilities. The risk is proportional to how much of the codebase is vibe-coded and whether rules file governance is in place. Without upgraded AppSec tooling, it’s a meaningful security gap.
What is the 27% figure, and where does it come from?
DX Research’s Q1 2026 analysis reported that 27% of production code is now AI-generated, up from 22% the prior quarter. At that share — carrying the vulnerability characteristics documented by Veracode and CSA/Endor Labs — SAST coverage gaps become an organisation-wide risk.
How does AI code generation change software supply chain risk?
AI-generated code introduces the hallucinated dependency vector. Supply chain risk traditionally centred on compromised known packages. AI adds packages that don’t exist yet, which attackers can pre-register once they know which names LLMs hallucinate. This expands the attack surface beyond what SCA tools calibrated for known-bad packages can handle.
Which is more important for AI code security: SAST, DAST, or SCA?
All three address different failure modes — none is sufficient alone. SAST misses hallucinated dependencies and context-dependent access control failures. SCA is most important for slopsquatting risk. DAST covers context-dependent flaws requiring runtime evaluation. The correct posture is a layered AppSec programme.
What does “vulnpocalypse” mean in the context of AI-generated code?
A term from Veracode’s research describing the projected accumulation of AI-era security vulnerabilities as AI code scales without adequate detection tooling. A genuine risk trajectory for teams managing security debt.
How do I know if my current SAST tool has been updated for AI-generated code risks?
Check for four capabilities: prompt-injection sink detection for LLM API calls; SCA integration and package registry verification; AI-specific vulnerability pattern libraries updated post-2024; and documentation of how the tool handles AI coding assistant output. If your vendor can’t answer to those four, assume the gap exists and layer in SCA and DAST coverage for AI-generated code sections of your codebase. This article is part of our AI code security overview, which covers the full landscape from tooling failures to compliance requirements.
