# The AI Code Vulnerability Problem Isn't About Which Model You're Using
Developers are asking the wrong question. The debate raging across engineering teams — GPT-4 or Claude? Copilot or Cursor? — turns out to be mostly noise when it comes to security outcomes. New research pinpoints what actually determines how dangerous AI-generated code is: the framework it's written for.
The headline number is bad enough: AI-generated codebases contain an average of 15 vulnerabilities each. But the more important finding is buried underneath that average. The variance between the safest and most dangerous AI-generated projects isn't primarily explained by which large language model generated the code. It's explained by which framework that model was writing for.
That's a shift in how the industry needs to think about AI coding risk — and most organizations haven't made it yet.
## Fifteen Vulnerabilities Doesn't Mean What You Think
When researchers say "15 vulnerabilities per codebase," the natural reaction is to treat that as a uniform threat level. It isn't. That average is doing a lot of work smoothing over scenarios that look radically different in practice.
A Spring Boot API with three high-severity injection flaws is a different animal than a React frontend with twelve medium-severity XSS issues — even if both codebases clock in at "15 vulnerabilities." Attack surface, exploitability, and blast radius vary enormously. The number by itself tells you that AI-generated code has a security problem; it doesn't tell you where the bodies are buried in your specific stack.
The framework finding is what makes this actionable. When AI models write, say, PHP with raw database queries, they reproduce the patterns that PHP developers themselves have reproduced for decades — because that's what the training data reflects. A model generating code in a framework with strong ORM defaults and convention-over-configuration security posture will produce structurally safer output, not because the model is smarter, but because the framework's guardrails survive translation.
## The Model Obsession Obscures What Actually Matters
Security teams, CTOs, and procurement committees have spent enormous energy evaluating AI coding assistants on capability benchmarks. How many LeetCode problems can it solve? Does it understand complex type constraints? Can it refactor legacy code?
Security benchmarks exist — CyberSecEval, SecurityEval, others — but they're rarely the deciding factor in vendor selection. The assumption, often unstated, is that a more capable model will naturally produce more secure code. This research suggests that assumption is weak.
A highly capable model writing raw Node.js/Express without security middleware doesn't gain much from its reasoning ability. It still reaches for res.send(userInput) and string-concatenated SQL because that's how a significant chunk of Express tutorials and Stack Overflow answers are written. The model faithfully reproduces the ecosystem's patterns — including its vulnerabilities.
Meanwhile, the same model writing Django benefits from a framework where CSRF protection, ORM parameterization, and template auto-escaping are the path of least resistance. The model doesn't need to know better; the framework pulls it toward safety by default.
## Where This Plays Out in Real Codebases
The practical implication breaks down by a few common scenarios:
Greenfield projects with AI assistance — teams building new services with AI help often default to whatever framework the model seems most fluent in, or whatever's trendy. If that's bare Express or raw PHP, the security debt accumulates fast, invisibly, because the code *runs* and *looks* correct.
AI-assisted migration work — converting legacy codebases with AI generates huge vulnerability surface. The model is working from old patterns and porting them faithfully, including decade-old authentication logic and unparameterized queries.
AI in low-oversight contexts — "vibe coding," prototypes that become production, hackathon code that ships. These are overwhelmingly framework-agnostic or framework-naïve environments, and they're exactly where the 15-vulnerability average probably looks more like 30.
The framework pairing finding suggests organizations should be asking a question they largely aren't: "What's our AI coding policy by framework?" Not all codebases are equal risk, and not all AI-generated code is equally likely to produce security issues based on what it's writing for.
## What Security Teams Can Do Right Now
Runtime validation and SAST tools are obvious starting points, but they're reactive. The more durable intervention is upstream:
---
## HackWire Analysis
The framing of "AI models introduce vulnerabilities" has let framework vendors, enterprises, and the AI industry itself off the hook for a more uncomfortable conversation.
If the model matters less than the framework, then part of this problem is a framework ecosystem problem — and framework maintainers, the open source community, and the enterprises that standardize on particular stacks share accountability for what AI coding tools produce at scale.
This also fits a pattern that security researchers have been pointing at for a while: LLMs are extraordinarily good at reproducing existing patterns, which means they're extraordinarily good at reproducing existing *mistakes*. The SQLi-vulnerable PHP tutorials that have polluted the web for twenty years didn't disappear from training data. They're now being emitted at code-generation speed.
What most coverage of this research misses is the supply chain angle. The 15-vulnerability-per-codebase figure matters for the team shipping that codebase. It matters more for the open source packages being written with AI assistance and published to npm, PyPI, and crates.io. When AI-assisted code enters the supply chain, the downstream exposure multiplies across every application that takes a dependency on it.
Security audits of AI-generated open source packages are not keeping pace with AI-generated open source package creation. That gap is where the next wave of supply chain compromises is incubating.
The right response from organizations isn't to ban AI coding tools — that ship has sailed. It's to treat AI-generated code with the same suspicion they learned (sometimes painfully) to apply to unvetted dependencies. And to pick their frameworks like the security decision it turns out to be.
— HackWire Editorial
---
## Related Coverage