48% of AI-Generated Code Is Insecure. How Should AppSec Process Change?

In March 2026, Snyk published a number: 48% of AI-generated code contains security vulnerabilities. At the same time, Veracode tested over 100 LLMs across 80 coding tasks and found 45% of AI-generated code introduces OWASP Top 10 vulnerabilities. 

And a cherry on top: CodeRabbit production analysis found that AI-assisted code contains 2.74x more security vulnerabilities than human-written code.

 

Code volume growth

Historically, human-written code in industry-tracked datasets averaged 6 vulnerabilities per 1,000 lines of code. And roughly 27% of production code is now AI-generated, with some estimates putting the share at 41% to 46% of newly written code.

The math is simple: 

 

same issue density per line   х   multiplied by an order of magnitude

---

 

divided by review capacity 

 

Black Duck 2026 Open Source Security and Risk Analysis report captures the downstream effect: the average number of known vulnerabilities per codebase went from 280 to 581 in a single year, up 107%.

AI does not write bad code, it just writes more code, faster than AppSec processes were designed to physically absorb.

 

What this changes for AppSec

Three things break under new volume.

Scan frequency has to match code velocity

If developers ship 3x more code per sprint, scanning once before release misses two thirds of what was written.
The answer: SAST on every commit, SCA on every pull request, secrets detection at the pre-commit hook.

SCA matters more, not less

AI assistants pull dependencies aggressively. Snyk research found AI tools rarely validate package authenticity. SQ Magazine analysis tracked a 20 - 30% increase in dependency sprawl compared to manually written projects. When AI suggests import requests, it does not check whether the package is legitimate. That's an SCA job, and it should run on every PR.

 

Code review applies equally to human and AI code

An earlier Snyk survey found nearly 80% of developers admit bypassing security policies, and only 10% (god bless them) scan most of the AI-generated code they ship. Stack Overflow 2025 data shows developer trust in AI output significantly dropped to 29% (from 70% in 2023). Developers know the output isn't reliable, yet they ship it anyway.

 

Why static analysis still matters

There's a counter-narrative going around: AI can review its own code, so classical SAST is obsolete. It doesn't survive contact with the data, because LLMs are non-deterministic by design. The same input can produce different outputs.  “Looks like a vulnerability” is a probability judgment. 

SAST on the other hand produces deterministic output: a taint analysis either finds a path from source to sink, or it doesn't. For compliance evidence, for build gates, for sign-off, determinism is required.

Second reason classical AST holds: AI makes the same classes of mistakes humans make, often more reliably. Snyk documented that AI tools repeat the patterns developers accept due to reinforcement learning. Accepted vulnerable suggestions reinforce more vulnerable suggestions. The vulnerabilities are not novel: SQL injection, XSS, broken access control, insecure deserialization, hardcoded secrets. That’s what SAST was built to detect.

 

The AI supply chain

The AI supply chain itself: models, agent frameworks, prompt rules files, MCP servers connected to developer IDEs. Snyk ToxicSkills audit scanned 3,984 skills across AI agent marketplaces and flagged 1,467 packages with at least one issue, including 534 critical. Attack vectors: prompt injection in skill metadata, base64-encoded droppers in installation scripts, curl-bash chains hidden in documentation.

This is supply chain risk in a new form. Defensive practices are the same as for npm and PyPI: SBOM generation extended to AI components, reachability analysis, typosquatting detection, signed packages.

DerScanner SCA handles this with reachability analysis that tells you whether a vulnerable function is actually invoked from the application. Plus typosquatting detection, MavenGate monitoring, starjacking analysis, and dependency health scoring.

 

What to do this quarter

1. Move SAST into the commit hook and PR gate. 

2. Run SCA with reachability on every PR. 

3. Generate SBOMs on every release, including AI components. 

4. Require code review on AI code at the same standard as code from an external contractor. 

5. Measure the gap between code written and code reviewed. If it's growing, the scanning cadence is behind.

The technology answer is not new. The forcing function is.

 

 

DerScanner SAST integrates with Jenkins, TeamCity, Azure DevOps, and GitLab CI. SCA includes reachability analysis and Supply Chain Security checks. Request a demo.