AI-Generated Code Security Risks, Named Honestly

AI-generated code security risks come from mirrored training data, not from a model trying to hurt you. Independent studies put the vulnerability rate at roughly 40 to 45 percent of AI-generated code samples, and that number does not shrink as models get bigger or newer. The fix is not a smarter model. It is a review harness that catches what the model cannot see about its own output.

I have watched teams treat GitHub Copilot and Claude Code output like a junior engineer's pull request: skim it, run the tests, ship it. That habit is exactly backward. A junior engineer knows what they do not know and asks. A language model does not know what it does not know. It writes a missing input check with the same confidence it writes a correct one, and both come out reading like production code.

Key takeaways

• Roughly 40 percent of GitHub Copilot-generated code contained exploitable weaknesses tied to MITRE's Top 25 CWE list, per a 2022 IEEE study that generated 1,689 programs across 89 scenarios.
• Veracode's 2025 GenAI Code Security Report found AI-generated code introduced risky flaws in 45 percent of tests across 100+ models, spanning Java, JavaScript, Python, and C#, and newer, larger models were not safer.
• LLMs hallucinate non-existent software packages in 5.2 percent of commercial-model outputs and 21.7 percent of open-source-model outputs, a supply-chain risk researchers now call "slopsquatting."
• Developers using an AI coding assistant wrote measurably less secure code, and were more confident it was secure, than developers working without one.
• Static analysis and secret scanners catch the patterns above reliably. They do not catch code that is syntactically clean and wrong for your system, which is why review stays a human job.

What Counts as an AI Code Security Risk

An AI code security risk is any vulnerability, weakness, or supply-chain exposure that a model introduces into generated code because it reproduces a pattern from training data or invents something that does not exist. That covers two different failure classes, and conflating them is where most review processes go wrong. The first class is ordinary: missing input validation, hardcoded secrets, weak authentication checks, injection flaws. The second class is specific to AI: fabricated package names, invented API methods, configuration that looks plausible and was never real.

Both classes pass a code review that only checks whether the code runs. Both classes pass unit tests written to confirm the happy path. Neither gets caught by asking whether the code compiles, because both compile fine.

The Vulnerability Patterns That Show Up Most Often in AI-Generated Code

Pearce et al. ran the study that put a number on this: Asleep at the Keyboard? tested GitHub Copilot against 89 scenarios built around MITRE's Top 25 Common Weakness Enumeration list and generated 1,689 programs. About 40 percent contained an exploitable weakness. The patterns were not exotic. SQL and command injection from string-built queries instead of parameterized ones. Hardcoded credentials sitting in the first draft, because a plausible-looking example credential is exactly what shows up across millions of public repos. Missing or backwards authorization checks, where the code confirms a user is logged in but never confirms they are allowed to touch this record.

Picture a typical review I run: an endpoint handler generated in a single prompt, tests green, code readable. The query concatenates a user_id straight into a string. It works in the demo because the demo never sends a malicious id. It ships because nobody asked the one question that matters: what happens if this input is hostile.

Why AI Models Reproduce Insecure Patterns

The mechanism is not a mystery. Training data is public code, and public code is full of the exact mistakes these studies catalog. A model trained to predict the next plausible token will predict the next common token, and the common pattern for a quick database lookup is the one without parameterization, because that is what got written and merged a million times over. The model is not deciding to skip validation. It is completing a pattern, and the pattern is insecure more often than it is secure.

This is also why the fix is not a better prompt. A system prompt that says "write secure code" nudges the distribution slightly. It does not change what the model learned about what typical code looks like. The difference between AI-native and AI-assisted work matters here: an assisted workflow still has a human typing the query, who at least has a chance to notice the string concatenation. A model generating the whole function has no such checkpoint unless you build one back in.

Package Hallucination: The Supply-Chain Risk Unique to AI Code

Slopsquatting is the term researchers now use for a risk with no equivalent in human-written code: a model inventing a package name that sounds real, is not, and gets installed anyway. Spracklen et al. ran a 2025 USENIX Security study across 576,000 code generations from 16 models and found commercial models hallucinated a nonexistent package 5.2 percent of the time. Open-source models did it 21.7 percent of the time. Across the full sample, the study surfaced more than 205,000 unique fabricated package names.

The attack writes itself once the pattern is known. An attacker watches which hallucinated names repeat across models and prompts, then publishes a real, malicious package under that exact name. The next developer who gets the same hallucination and runs pip install or npm install pulls the attacker's code, not a typo, a suggestion the model made up with total confidence.

I have seen a version of this in a dependency file generated during a scaffolding pass: an import for a package that looked like a natural extension of a well-known library, formatted exactly like every real import around it. Nothing about it looked wrong. That is the whole problem with a hallucinated package. It does not look suspicious. It looks like every other line.

If your team is shipping AI-generated code into production without a build process that catches this class of risk, that gap is worth closing before the next scaffold, not after an incident. ViitorCloud's SaaS product engineering team builds dependency verification and secure-by-default patterns into the delivery pipeline itself, not as a review someone remembers to run.

Why a Bigger, Newer Model Doesn't Mean Safer Code

Veracode's 2025 GenAI Code Security Report tested more than 100 large language models across Java, JavaScript, Python, and C#. AI-generated code introduced risky security flaws in 45 percent of tests, and the report's most useful finding is the one nobody wants to hear: newer, larger models were not meaningfully safer than older, smaller ones. Model scale improves fluency and task completion. It does not train the model to prefer a parameterized query over a concatenated one, because that preference was never the optimization target.

That has a direct business consequence. A team that budgets security risk down as it upgrades to the newest model is budgeting against the evidence, not with it. The review harness that catches injection flaws in code from last year's model has to catch the same flaws in code from this year's, because the underlying rate does not move with the version number.

The Overconfidence Trap

Perry et al., in a 2023 ACM CCS study, found developers using an AI coding assistant wrote measurably less secure code than developers working without one, and were more confident their code was secure. That combination is worse than either problem alone. Less secure code paired with low confidence gets double-checked. Less secure code paired with high confidence ships.

This is the actual mechanism behind most of what gets called "vibe coding" security failure: not that the code is bad in some new way, but that the speed of getting to green tests removes the pause a developer used to take before merging something they wrote slowly and were unsure about. The model sounds sure. The tests pass. The reviewer, who is often the same person who wrote the prompt, inherits that same false confidence.

The Review Harness: How to Evaluate AI-Generated Code Before It Ships

Static analysis, secret scanners, and dependency verification catch the vulnerability patterns above reliably, and every team shipping AI-generated code should run all three before merge. But they miss the risk that matters most: code that is syntactically clean, passes every automated check, and is still wrong for your system. An access-control check that is technically valid but wrong for your multi-tenant model will not trip a scanner. No tool catches an intent-level bug. Only a reviewer who knows the system does.

Automated scanning is the floor, not the review. Here is the harness I run before AI-generated code merges:

• Run SAST (static application security testing) on every diff, not just release branches, so injection and hardcoded-secret patterns surface at commit time.
• Run a secret scanner as a pre-commit hook, not a CI-only check, because a leaked key in history is a leaked key even after the final commit removes it.
• Verify every new dependency against the real registry before install, not after, to close the slopsquatting window.
• Have a human who owns the system, not the person who wrote the prompt, review any change touching authentication, authorization, or data access.
• Ask one question the scanner cannot answer: is this access check correct for our actual tenancy model, not just syntactically present.

This is the same discipline I lay out for the broader shift in how software gets built in the AI-native SDLC: the human's job narrows to specifying intent and evaluating the result, and evaluating security is not optional inside that job. A proper AI code review process is where that evaluation happens, line by line, before the merge, not after the retro.

Tools That Automate the Catch

None of these tools replace the reviewer above. They remove the excuse for skipping the mechanical checks a human should not be doing by hand.

• SAST scanners (Semgrep, CodeQL, Snyk Code) catch the injection, hardcoded-secret, and missing-validation patterns that show up in roughly 40 to 45 percent of AI-generated samples.
• Secret scanners (Gitleaks, TruffleHog) catch credentials the model wrote into the first draft because a real-looking example credential was sitting in its training data.
• Dependency and package verifiers confirm every import resolves to a real, published package before install, the direct countermeasure to slopsquatting.
• Software composition analysis tools flag known-vulnerable versions once a dependency is real and installed, which matters as much for AI-suggested packages as for human-chosen ones.

None of this is a reason to slow down AI-assisted development. It is a reason to build the harness once, run it on every diff, and stop treating a green test suite as proof of security. The deeper argument for building that discipline into your delivery process from day one, not bolting it on after an incident, is in The AI-Native SDLC.

Is AI-generated code less secure than code written by humans?

The evidence points to less secure, not because the model is careless but because it reproduces the average of its training data, which includes a lot of insecure public code. Perry et al. found developers using an AI assistant wrote measurably less secure code than a control group, while also feeling more confident in it.

What is slopsquatting and why does it matter for AI-generated code?

Slopsquatting is an attacker publishing a real, malicious package under a name a language model commonly hallucinates. Research found commercial models invent nonexistent package names 5.2 percent of the time and open-source models 21.7 percent of the time, giving attackers a predictable target to squat on.

Does GitHub Copilot or ChatGPT write vulnerable code by default?

Independent testing puts the baseline vulnerability rate for AI-generated code around 40 to 45 percent of samples, across Copilot and more than 100 other models tested in Veracode's 2025 report. No mainstream coding assistant ships with security guarantees by default; all of them need a review harness on top.

How do I review AI-generated code for security issues before shipping it?

Run SAST and secret scanning on every diff, verify new dependencies against the real package registry before install, and have a human who owns the system review anything touching authentication, authorization, or data access. Automated tools catch known patterns; only a reviewer catches code that is clean and still wrong for your system.