AI Coding Assistants Are Pulling in Open Source Packages Faster Than Anyone Can Check Them

Key points

• AI coding assistants suggest open source software packages faster than traditional security reviews can vet them, according to analysis from software supply chain firm ActiveState.
• Some AI-suggested packages do not exist at all: the model invents a plausible name, and attackers register that name with malicious code inside.
• Governance needs to move to the moment a developer picks a package, not after it lands in the codebase.
• Ordinary users of apps built this way rarely see the risk directly, but they inherit it through the software they run every day.

AI coding tools now write a large share of the software the world runs on. They also decide, quietly, which open source building blocks that software depends on. And that second habit is turning into a security problem.

When a developer asks an AI assistant to "add a function that resizes images" or "connect to this database", the assistant often reaches for an open source package, meaning a free chunk of code written by someone else and published to a public library like npm or PyPI. The developer accepts the suggestion. The package gets pulled in. The app ships.

The problem is speed. Human security teams were built to review dependencies one at a time. AI assistants add them by the hundred, per developer, per week.

What actually goes wrong here?

Three things, and none of them are exotic. First, the AI suggests a real package that happens to be poorly maintained, abandoned, or already known to contain a vulnerability. Second, the AI suggests a package whose latest version was recently taken over by an attacker, a tactic called a supply chain attack. Third, and stranger, the AI suggests a package that does not exist.

That last one has a name: slopsquatting. The model hallucinates a plausible-sounding library, say fast-image-utils, that nobody has ever published. Attackers watch for these hallucinations, register the name themselves, and upload malicious code. The next developer who accepts the same suggestion installs the trap.

As first reported by BleepingComputer in coverage of ActiveState's analysis, the scale of AI-driven ingestion is the core issue. It is not that AI picks worse packages than humans on average. It is that AI picks so many, so quickly, that the old review model breaks.

Why can't security teams just catch it later?

By the time a bad package is "later", it is already in the build, in the container image, and often in production. Scanning tools that look for known-bad code after the fact still matter, but they run after the horse has left. A malicious package that steals environment variables on install has already stolen them before any scanner sees it.

ActiveState's argument is that governance has to move left, to the moment of selection. That means checking a package's reputation, maintainer history, licence, and known vulnerabilities before a developer clicks accept on the AI's suggestion, not after.

How the risks stack up

Risk	What it means	Where it hits
Vulnerable package	Real library with a known flaw	Production apps
Hijacked package	Legitimate library taken over by an attacker	Build systems, developer laptops
Slopsquatting	AI invents a package name; attacker registers it	New projects, prototypes
Abandoned package	No maintainer, no patches coming	Long-lived codebases

What does this mean for ordinary users?

Most people never touch a package manager. But the banking app on your phone, the booking site you used last week, and the payroll system your employer runs are all built from these same open source pieces. When a malicious library slips into a popular app, the fallout, stolen credentials, leaked data, hijacked accounts, lands on the customer.

There is no consumer action here. This one is on the vendors. Ask your software suppliers, especially the ones handling your personal data, whether they know what their AI assistants are pulling in, and whether anyone is checking before it ships.

Common questions

Is it safe to let developers use AI coding assistants at all?

Yes, with guardrails. The tools save real time. The fix is not to ban them but to put automated package vetting between the AI's suggestion and the developer's codebase.

What is slopsquatting in one sentence?

Attackers register fake package names that AI models are known to hallucinate, so the next developer who trusts the AI's suggestion installs malicious code.