Who Vets AI’s Code? The Scale Challenge Facing Open Source Ingestion

What happened

BleepingComputer reports ActiveState’s case that AI coding tools can introduce unvetted or hallucinated open source dependencies faster than traditional security reviews can keep pace. The problem is not a single bad package slipping through a known process. It is a change in the rate at which dependency decisions get made. A developer using an AI coding tool can accept a suggested library, import, or lockfile entry in the same motion as accepting a function body. That suggestion may name a real package the team never evaluated, or a package name that looks plausible and is not the artifact the model implied. ActiveState’s answer is specific: govern packages at the point of selection, before they enter the development pipeline. The claim is that review after ingestion is already the wrong layer once generation speed exceeds review capacity.

The mechanics sit in how an AI coding tool writes software. The model does not only emit application code. It also emits the graph of other people’s code that application will call: package names, version ranges, and transitive requirements that a package manager will later resolve. Traditional security review assumes a human chose those names, that a ticket or pull request made the choice visible, and that a scanner or review board could inspect the artifact after it appeared in a manifest. Hallucinated dependencies break the first assumption. The name may be invented, mistyped toward a lookalike, or drawn from training residue rather than from a catalog the organization trusts. Unvetted dependencies break the second. The name may be real and widely used, yet nobody on the team decided it belonged in this product. In both cases the pipeline still behaves as designed. A resolver fetches what the manifest asks for. A build runs. A review queue, sized for human-paced additions, sees a burst of new nodes it did not budget for. ActiveState’s selection-time control is an attempt to put a gate where the name is chosen, not where the tarball is already cached.

The technical detail

That gate matters to engineers because the people closest to the AI tool are also the people least positioned to treat every suggestion as a supply-chain event. A coding assistant is used to reduce friction. Asking that same user to pause and run a full package review on every autocomplete-adjacent import fights the reason the tool was adopted. Once the name is in the repository, downstream systems treat it as intent: CI installs it, scanners score it, and incident response inherits it. Builders who own lockfiles, private registries, or language-specific installers are the ones who will feel the mismatch first. Their tools already encode “if it is listed, fetch it.” They do not encode “if a model listed it, treat it as unconfirmed.” Governing at selection is a way to keep the installer honest without requiring every security review to happen after the fetch.

Why it matters for builders

The market context is a collision between two mature practices that used to be sequenced. Open source ingestion has long been a known risk surface: organizations already argue about allowlists, SBOMs, and when a new library is allowed in. AI coding tools compress the front of that sequence. Selection, which used to be a slow human act, becomes a high-volume side effect of code generation. Traditional security reviews were built for the old tempo. ActiveState is not describing a new class of vulnerability so much as a throughput problem on an old control. Vendors and platform teams that sell or operate package governance will read this as a reason to move policy earlier. Teams that invested only in post-merge scanning will read it as a warning that their queue is now the bottleneck, not the last line of defense. Competitors in the same space will make similar claims; the differentiator ActiveState is pushing in this account is the location of the decision, not a new scanner feature after the fact.

Market and competitive context

The practical takeaway is operational, not rhetorical. If an organization keeps using AI coding tools, it should treat package names as a controlled input at the moment they are proposed, not as an output to be cleaned up in the pipeline. That means the selection surface has to be explicit: what catalog is allowed, who can add a name, and whether an AI suggestion is allowed to write a manifest line without passing that control. What to watch next is whether teams actually bind those rules to the tools developers already use, or whether they leave a gap between the assistant and the registry. A policy that lives only in a later review will keep losing to the generation rate BleepingComputer’s report attributes to these tools. A policy that lives at selection can fail too, but it fails before the pipeline has already treated the package as present.

What to watch next

Risks and open questions remain inside that prescription. Unvetted and hallucinated are not the same failure, and a single selection gate may handle them unevenly. An allowlist stops a name that was never approved; it does not by itself prove the approved name is the one the model meant. A hallucinated name that happens to resolve to a real project is a different incident from a name that resolves to nothing, and both are different from a popular package that is real, malicious, or abandoned. ActiveState’s argument assumes organizations can define “selection” clearly enough to intercept AI output. That assumption is unproven in the summary. It is also unclear how the control behaves when the model writes transitive requirements the developer never sees, or when the same suggestion is accepted across many repositories faster than any central list can be updated. Related prior art is the older discipline of curated internal indexes and approved-package programs. Those programs already tried to govern ingestion before the build. The new pressure is that AI coding tools can propose candidates faster than those programs were staffed to accept or reject them. The open question is whether moving the gate earlier is enough, or whether the gate itself has to be built for machine-scale proposals rather than human-scale requests.