How AI-Assisted Coding Is Changing Application Security

AI-assisted coding tools write plausible-looking code fast, and "plausible-looking" is doing a lot of work in that sentence. These tools rarely produce code that obviously fails, the real risk is code that looks correct enough to ship without the review it actually needed.

The package that was never real

A 2025 USENIX Security study tested how often code-generating models invent package names that don't exist, dependencies a developer would then try to install. Across roughly 576,000 samples, 19.7% contained at least one hallucinated package name, with open-source models hallucinating far more often than commercial ones, 21.7% versus 5.2%. The security industry now calls this pattern slopsquatting, an attacker registers the exact fake package name a model keeps inventing, and waits for developers to install it. A 2025 proof-of-concept package accumulated more than 30,000 real downloads in three months before anyone treated it as a real threat class.

It's already happened for real, not just in a lab

This stopped being theoretical in January 2026. Aikido Security reported a live malicious npm package, react-codeshift, that propagated through 237 repositories by exploiting exactly this pattern, a name an AI coding assistant plausibly invents, registered and waiting. A 2026 replication study testing five frontier models, including Claude Sonnet 4.6 and Claude Haiku 4.5, against nearly 200,000 prompts found hallucination rates had dropped to between 4.6% and 6.1%, real progress, but notably, the same 127 fake package names showed up across all five models tested. That overlap is the part that should concern a security team more than the raw percentage, it means an attacker doesn't need to guess at random, there's a shared, predictable set of names worth squatting on.

The risk that doesn't make headlines: subtle logic flaws

Hallucinated dependencies are the easiest version of this risk to measure, which is why it's the one with a clean statistic. The harder version is the one our secure code review work finds constantly, AI-generated code that handles the happy path correctly and gets an edge case, an authorization check, or an input validation boundary subtly wrong in a way that passes a quick glance and a basic test suite. Our pieces on hardcoded secrets in code and why SQL injection still works cover vulnerability classes that predate AI-assisted coding by decades, what's changed is the volume of code being shipped without a human who deeply understands every line of it.

The fixes, and what they don't cover

None of the fixes here are exotic. Lockfiles and a registry allowlist stop a hallucinated package from silently resolving to whatever got registered under that name. Verifying a suggested dependency actually exists, and is the package you think it is, before installing it closes the slopsquatting path specifically. Neither of those addresses the subtler logic-flaw risk, that still requires the same thing it always has, a human reviewer who reads the code rather than trusting that it compiles and passes tests.

Where this fits into a real security program

None of this is a reason to slow down AI-assisted coding adoption. It's a reason to make sure code review hasn't quietly become a rubber stamp. If your team has shipped a meaningful amount of AI-assisted or AI-generated code without a corresponding increase in review rigor, that's a real, specific gap worth closing before it shows up in an incident instead of a code review. Our Secure Code Review service is built around exactly that kind of manual review, chaining findings the way an attacker would rather than scanning for known patterns alone.