AI coding assistants and the surface your scanner does not see

On August 4, 2026 an attacker with a stolen maintainer token published poisoned versions of the keyv and cacheable package families to npm. Within an hour the ChainDrop worm had reached more than 440 packages and 2,200 versions, an estimated 2 billion monthly installs, and the compromised builds carried valid SLSA Build Level 3 provenance attestations. Provenance proved the pipelines ran as declared. It did not prove the sources were trustworthy. That is the failure mode most teams are one bad token away from meeting on their own, and it is the honest limit on the control the industry currently recommends most loudly for AI-generated code.

We wrote this piece because assistants have moved from an experiment to a load-bearing part of most delivery pipelines, and the security controls around them still assume a human authored every line. That gap is now measurable. Veracode's 2026 GenAI Code Security Report found that roughly 44% of AI code-generation tasks introduced a risky security vulnerability, and that the average security pass rate across models is 56%, essentially unchanged from the 55% they measured a year earlier. Veracode's Spring 2026 update is titled, fairly, "despite claims, AI models are still failing security"; newer and larger models are not measurably safer. Field data from AI-assisted developers inside a Fortune 50 sharpens the picture: they commit at three to four times the rate of their peers, and introduce security findings at ten times the rate. Volume and defect rate compound. About 67% of developers report increased debugging time on AI-assisted work. VulnCheck's state of exploitation for the first half of 2026 is the honest counterweight: of 1,061 vulnerabilities attributed to AI-assisted discovery, only 14 (roughly 1.3%) have been confirmed exploited in the wild. AI is generating far more findings than exploitation, for now. The concern this piece is about is the distribution shift, not a wave of AI-authored zero days.

Three surfaces the SDLC just grew

1. Hallucinated and typo-adjacent packages entering lockfiles

The academic version of this problem is not new. Spracklen et al, "We Have a Package for You!" (USENIX Security 2025), measured roughly 19.7% of recommended packages as hallucinations across 576,000 samples from 16 LLMs. Socket's parallel study identified 53 slopsquatting targets across five frontier models. Bar Lanyado did the earliest package-hallucination research at Vulcan Cyber in 2023, and returned in 2024 at Lasso Security with the huggingface-cli upload on PyPI that recorded 30,000+ authentic downloads in three months, including an Alibaba public repository README that pasted the hallucinated install command verbatim. Seth Larson at the Python Software Foundation coined the term slopsquatting in April 2025, and the Cloud Security Alliance followed with a research note on April 19, 2026.

The victim list is now short but real. The unused-imports package on npm, a model hallucination of the actual eslint-plugin-unused-imports, was still recording roughly 233 weekly downloads in early February 2026 after npm security-held it. Charlie Eriksen's react-codeshift case is the more instructive one: a conflation-style hallucination that propagated through 237 repositories via AI-generated agent skills, with daily downloads driven by autonomous agents executing their own generated output. The loop closed without a human in it. Slopsquatting is no longer a demonstration; it is a documented registry attack pattern with named victims and steady traffic.

2. Insecure patterns copied at scale from training data

Pearce et al, "Asleep at the Keyboard?" (IEEE S&P 2022), ran 1,689 programs against 89 CWE scenarios and found roughly 40% vulnerable. Perry et al at CCS 2023 added a second, worse finding: AI-assisted developers write less secure code and trust it more. GitClear's 2025 developer report saw four times the growth in code-clone patterns and a collapse in refactoring frequency, which is what you expect if a fleet of assistants is emitting the same neighborhoods of code many times over. Combine that with the field three to four times commit-rate multiplier and a ten times defect-rate multiplier, and the shape of the problem is a single vulnerable pattern reappearing in far more places than any code review workflow was built for. The response cannot be "review harder"; the review budget does not scale with commit rate.

3. Provenance loss

Nobody in most organizations can tell you which lines of code were written by a human, which by an assistant, and which by an agent executing an assistant's own output. Without that, you cannot scope review to the higher-risk subset, cannot correlate incidents back to a generator, and cannot audit whether a control ("we review all AI-generated changes") is actually being applied. The industry-facing risk here is OWASP's LLM03:2025 (Supply Chain), which names the AI supply chain but does not yet prescribe a tagging convention. ChainDrop is the honest limit of the control we already have: the compromised packages held valid SLSA Build Level 3 attestations, and the attestations were correct about what the build pipeline did. They said nothing about whether the source going in was trustworthy. Microsoft's ChainDrop write-up and Elastic Security Labs land on the same conclusion, so provenance for generated code is a control we need next to attestation, not instead of it.

What is already covered, and what is still open

Most of the raw material for a safe assistant workflow is already in the toolbox. Software composition analysis, secrets scanning, container image scanning, dependency allow-listing, private proxy registries, and SLSA provenance attestation are mature controls with widely deployed implementations. Slopsquatting itself is a specific case that fits the existing model of typosquatting, and both npm and PyPI have security-hold workflows for removing named packages once reported. OWASP LLM03:2025 provides the risk vocabulary. On the assistant-builder side, the NCSC and CISA guidelines for secure AI system development speak to teams that build AI systems. All of that is prior art we should apply, not reinvent.

Three things are, as of writing, genuinely open. No public guidance from CISA or NCSC targets AI coding assistants as a consumed category; the existing material is aimed at builders, and the secure adoption playbook for a team that merely uses assistants is still thin. Longitudinal data connecting AI-code adoption to exploited CVEs in production also does not exist, so any claim linking the two beyond correlation is still speculation, which is why the piece treats defect rate and exploitation rate as separate curves. And provenance for generated code has no standard at all, which is exactly what ChainDrop just showed: build-level attestation is a claim about the pipeline, not about the trustworthiness of the source that went in.

What to change in the pipeline this quarter

The point of naming three surfaces is to make each one a policy target. Wire SCA and secrets scanning into the same PR gate the assistant is already feeding, so a fresh dependency added by an assistant faces the same check any human dependency would; the check must be blocking before merge, not advisory after. Route new packages through an internal proxy or allow-list, so an install cannot resolve to a name your registry has never seen and a hallucinated name fails closed at the fetch step. Tag AI-generated changes explicitly, whether by commit trailer, PR label, or a signed metadata field, so scoped review and future audit are possible; if you cannot answer "which of last quarter's commits was model-authored," the tag is missing. And treat assistant output as untrusted input to the pipeline the same way you treat an outside contributor's PR: reviewed and accepted or rejected, never bypassing controls because it came from an internal tool. None of these are new controls. What is new is applying them to a code source that most pipelines still implicitly treat as trusted.

What scanners structurally cannot see

Two things stay outside a scanner's reach even after the pipeline changes above. Reachability of generated code paths cannot be inferred from a lockfile alone; a hallucinated package that is imported but never called is a different risk from one wired into a hot path, and the field three to four times commit rate makes triage by hand a losing race. Provenance, per ChainDrop, cannot be inferred from an attestation alone; a valid Build Level 3 signature is a claim about the build environment, not the source going into it. Both belong in a control loop that consumes scanner output rather than replacing it: reachability comes from runtime evidence and BAS validation, and provenance comes from tagging what the assistant produced at the moment it was produced. Everything else the pipeline gate can catch is upstream of both.

CVEasy AI is the local-first CTEM platform because that separation is the whole point: keep detection where the code lives, and keep the AI assistance you add to review inside the same trust boundary as the exposure map it is reading. The scanner does the SCA and secrets work at the PR gate, and the parts it structurally cannot see get their own control loop next to it.