Your AI coding assistant just suggested a package. You accepted it in one keystroke. Nobody checked where it came from, whether it's still maintained, or whether the name it suggested even exists as the legitimate package you think it is.

That's not a hypothetical. That's the default state of most engineering organizations running AI coding tools today, and it's not because anyone is being careless. It's because the review step that used to catch a bad dependency, a developer pausing to search, read a README, and check a commit history, doesn't survive contact with a suggestion that appears inline and looks authoritative. The filter didn't get worse. It disappeared.

Key Takeaways

• AI coding assistants recommend open source dependencies at a volume no manual review process was built to handle, and they do it without evaluating security posture.
• Attackers exploit this directly through "slopsquatting": they register the malicious-package names AI models hallucinate, so an accepted suggestion can install compromised code instead of a real library.
• Scanning after the fact (what the industry calls Scan and Pray) finds a vulnerability once it's already in your environment. It doesn't stop it from getting there.
• Governing dependencies at the point of origin, what ActiveState calls Curate and Govern, means AI-suggested packages resolve from a vetted, built-from-source catalog instead of an open public registry.
• The industry average time to remediate a critical CVE runs 54.8 days. ActiveState's contractual SLA is 5 business days for critical vulnerabilities, 10 for high, and 30 for all others.

The Filter That Used to Catch Bad Dependencies Is Gone

Before AI tools, choosing a package involved a small amount of friction: search for it, skim the README, check when it was last updated. That wasn't a security review. But the friction did something useful. Packages that looked abandoned or felt off got skipped more often than not.

An AI suggestion removes that friction entirely. It appears inline, it looks authoritative, and accepting it takes one keystroke. The model isn't evaluating security posture when it makes that suggestion. It's pattern-matching against training data, which means it will just as readily suggest a package that's outdated, unmaintained, or compromised as one that's actively supported.

There's a more direct version of this risk, too, and it's not hypothetical. AI models sometimes hallucinate package names that don't exist, and attackers have already been caught weaponizing that pattern. Security researchers at Aikido documented a real case: an npm package called unused-imports, hallucinated by AI models in place of the legitimate eslint-plugin-unused-imports, turned out to carry malicious code. npm placed it under a security hold, and it was still recording roughly 233 weekly downloads months later, evidence of how long a hallucinated package can keep drawing victims even after it's been flagged. A developer who trusted the AI's suggestion and ran the install command got the attacker's version, not a real package, because the registry had no way to distinguish a hallucinated request from a legitimate one.

None of this requires a careless developer. It requires a governance model built for a world where a human was making every dependency decision. That world doesn't describe most engineering organizations anymore.

Why Scanning Doesn't Solve This

Software composition analysis tools are useful. They're also structurally late. A scanner tells you what's already in your environment. It does not tell you what's about to enter it, and it can't stop an AI assistant from suggesting a package five minutes before your CI pipeline pulls it in.

This is the distinction ActiveState calls Curate and Govern versus Scan and Pray. Scan and Pray is reactive: find the problem after it has already shipped, then triage. Curate and Govern is proactive: make sure only vetted, built-from-source components are available to pull from in the first place, so there's less for the scanner to find. The two aren't competitors. A scanner still matters. But a scanner can't be your only control when the volume of dependency decisions has moved to machine speed and your review process hasn't.

The 2021 Log4j vulnerability is the clearest illustration of why this matters at the transitive layer, not just the direct one. Organizations that had never heard of Log4j were running it anyway, because something they'd intentionally installed depended on it three or four layers down. Most teams have reasonable visibility into the packages they explicitly chose. Almost none have the same visibility into everything those packages brought with them. That's where an AI-accelerated dependency tree becomes a real problem: the volume of transitive dependencies grows every time a suggestion gets accepted, and the attack surface grows with it.

What Governing Dependencies at the Source Actually Looks Like

Governing AI-assisted coding means moving the security decision to before a package is available to pull, not after it's already in a build. In practice, that means every dependency, whether a developer typed it or an AI assistant suggested it, resolves against a curated, policy-governed catalog instead of an open public registry.

ActiveState builds that catalog from source, inside a SLSA Level 3 environment, across more than a dozen language ecosystems. If an AI coding assistant suggests a package that isn't already vetted, the request doesn't silently fall back to the public internet. It gets flagged, and the component can be evaluated and added to the governed catalog rather than pulled unverified.

Governance without a remediation commitment is still a backlog, though. When a vulnerability does surface in an approved component, most organizations are working against that 54.8-day industry average I mentioned above. That's over 7 weeks of exposure on a known, disclosed issue. ActiveState's remediation SLA is 5 business days for critical CVEs, 10 for high, and 30 for everything else, and the fix is rebuilt from source and redistributed automatically rather than handed back to your team as a ticket.

A Dependency Governance Checklist

Use this to find out where unvetted open source is actually entering your pipeline, not where you assume it is.

1. Identify the point of origin. Trace exactly where packages enter your software development lifecycle, and confirm whether developers and AI tools are pulling from a governed catalog or an open public registry.
2. Audit what your AI tools are actually installing. Review how your coding assistants suggest and import dependencies, and confirm there's a vetting step before an AI-suggested package gets installed, not after.
3. Measure your real remediation timeline. Track your actual mean time to remediate critical CVEs and compare it against the 54.8-day industry average.¹ If you don't know your number, that's the first gap to close.
4. Require provenance, not just a scan result. For every open source artifact, you should be able to answer who built it, where the source came from, and how it was compiled.
5. Automate the policy instead of documenting it. Guardrails that block unapproved packages upstream give security the enforcement they need without turning every package request into a manual approval queue that stalls engineering.

How ActiveState Helps

ActiveState's Curated Catalog puts a governed, built-from-source library between your developers, your AI coding assistants, and the public internet. When an AI tool suggests a dependency and a developer accepts it, the package it resolves to has already cleared a security threshold, been built from verified source, and carries full provenance, not just a scan result generated after the fact. When a CVE does surface, ActiveState's remediation SLA replaces an open-ended backlog with a contractual timeline your team didn't have to build or staff.

Want to see what a governed catalog looks like against your actual dependency tree? Talk to our team.

Jonny Rivera is Senior Director, Product Management at ActiveState, where he leads product strategy for the ActiveState Curated Catalog and the company's software supply chain security roadmap. He writes regularly about open source governance, dependency security, and the architecture decisions that determine whether a vulnerability reaches production in the first place.