AI coding assistants now suggest third-party packages in milliseconds, but UK infrastructure teams still lack the controls to stop hallucinated or malicious dependencies reaching production. Slopsquatting exploits this exact gap, and new telemetry shows most organisations have no dedicated process for it.
View the data behind this chart
| AI assistants used | AI used in PR review | Dedicated AI AppSec | |
|---|---|---|---|
| Organisations (%) | %85 | %38 | %9 |
What slopsquatting means for your pipeline
The mechanics are straightforward and that is what makes them dangerous. Large language models suggest package names based on statistical pattern-matching, not live registry verification, so an AI coding assistant can confidently recommend a dependency that simply does not exist in PyPI or npm. Attackers monitor public LLM output and developer repositories for these hallucinated names, register the dummy package with a malicious payload, and wait for an automated build to fetch it, according to BleepingComputer's analysis published by ActiveState.
For UK teams running cloud security measures alongside CI/CD automation, the worrying part is that no human ever deliberately chose the compromised package. The chain runs from AI suggestion, to non-existent registry entry, to attacker registration, to automated fetch, to compromised build, entirely without a decision point a security team could realistically intercept using legacy review.
The scale problem, in numbers
A USENIX Security study analysing sixteen popular code-generation models across more than 500,000 code samples found a measurable percentage of AI-suggested package names simply do not resolve to real packages at all, and that among the ones that do resolve, nearly half carry known CVEs or outdated releases, per BleepingComputer's reporting.
This is not a theoretical concern. Early in 2026, researchers tracked a single hallucinated npm package name, react-codeshift, that originated from 47 AI-generated agent skills in one commit and spread through forks to more than 230 repositories before anyone noticed a human had never actually selected it. Separately, a CodeRabbit review of 470 open-source pull requests found AI-co-authored contributions carried 70% more defects than human-authored code, despite appearing clean on the surface.
Why post-commit scanning can't keep up
Traditional Software Composition Analysis runs after code is written or after a pull request opens. That workflow assumed dependencies entered a codebase at human speed. AI assistants have removed that assumption, and Kusari's Application Security in Practice telemetry, cited by BleepingComputer, shows the resulting governance gap starkly: 85% of organisations already use AI coding assistants, only 38% use AI to assist PR-stage review, and just 9% have dedicated AI AppSec controls in place.
When alerts arrive after the fact, at machine speed, they simply pile up as backlog noise engineers learn to ignore. For teams evaluating vulnerability management solutions, the practical implication is that scan cadence matters less than where in the pipeline the check actually sits.
What UK regulators and standards bodies are already saying
The UK's National Cyber Security Centre has been explicit that AI systems increasingly connect to company data and operational technology, and that threat actors will almost certainly exploit that expanded surface through software vulnerabilities and supply-chain attacks, not just prompt injection. The NCSC's guidance calls for up-to-date security measures across AI systems and their dependencies, and its Cyber Assessment Framework requires organisations to have a clear understanding of service dependencies before AI tooling is trusted in production paths.
The NCSC's separate advice on AI-assisted development, sometimes framed around the risks of unchecked "vibe coding", recommends review, dependency understanding, vulnerability checking and verification before AI-generated code is used at all. Computer Weekly reporting adds that secure AI pipelines should include CI/CD best practice, code signing and model integrity checks, alongside scanning of third-party libraries for backdoors and licence problems — all points that map directly onto the ingestion questions UK buyers should be asking their tooling vendors now.
Governing the point of selection, not just the build
The direction of travel across the sources is consistent: defence has to move left of the IDE, to the moment a package is selected rather than the moment it is merged. That means restricting workstations and AI agents from querying public registries directly during code completion, isolating newly introduced dependencies in a sandbox for reachability and vulnerability analysis before they reach a primary branch, and replacing reactive CVE counting with proactive curation of what an AI model is even allowed to suggest.
Cisco's zero-trust guidance for agentic AI lists tool misuse and agent-to-agent manipulation alongside prompt injection as key risks, reinforcing that dependency chains, not just prompts, need controlling. This is consistent with broader Zero Trust principles applied to the software supply chain rather than just network access, and it overlaps heavily with existing supply chain security for open source ingestion practices UK teams should already be tightening.
View the data behind this chart
| No ingestion… | Post-commit SCA | Selection-point… | |
|---|---|---|---|
| When risk is caught | Never / breach | After merge | Before import |
| Developer friction | Low (unsafe) | High (backlog) | Low (governed) |
| CVE exposure vs baseline | Baseline | Modest reduction | ~95% lower |
| Handles machine-speed AI | No | No | Yes |
What this means for UK infrastructure buying decisions
For platform engineering and AppSec leads, the buying question shifts from "which SCA tool scans fastest" to "who is vetting the package before an AI assistant ever suggests it". Vendors including ActiveState now position curated, pre-vetted repositories as an ingestion gateway sitting between public registries and developer tools, with vendor-reported reductions in CVE exposure of roughly 95% when organisations route AI-suggested dependencies through a governed source rather than the open internet — a claim worth testing against your own environment before procurement, not accepting at face value.
Wider platform players such as IBM's Concert reflect the same market shift toward dependency visibility across environments. Before any procurement decision, UK teams should run a proper IT risk assessment services exercise against their current CI/CD ingestion path, map it using attack surface management techniques, and check how any AI agent framework in use handles dependency resolution — a growing concern flagged in reporting on AI agent framework vulnerabilities.
- 01BleepingComputer — Who Vets AI's Code? The Scale Challenge Facing Open Source Ingestion · 13 August 2026
- 02NCSC — AI to 2027: Threat Assessment · 1 January 2026
- 03NCSC — AI and cyber security: what you need to know · 1 January 2026
- 04NCSC — The vibe coding spectrum: an approach to AI-assisted software development · 1 January 2026
- 05NCSC — Cyber Assessment Framework, Principle A3: Asset Management · 1 January 2026
- 06Computer Weekly — Assessing the risk of AI in enterprise IT · 1 January 2026
- 07Cisco — Zero Trust for Agentic AI · 1 January 2026
- 08The Register — CyberUK: AI deployment risks · 14 May 2025