Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Preventing AI package hallucination attacks starts with treating every package name suggested by a coding model as untrusted input. Check it against the intended registry and review its identity and history before installation; a registry lookup alone is not enough, because an attacker may already have published a malicious package under a hallucinated name. Gate agent-initiated installs, lock and review dependencies, route downloads through controlled registries, and keep install-time code away from CI secrets.
How a hallucinated package becomes a CI/CD attack
A package hallucination occurs when generated code names a package that does not exist in the relevant registry, or identifies a package that is not the intended dependency. The name may look plausible enough to pass a quick review. If an attacker registers it first, installing it can turn a model error into a software supply-chain attack—a technique often called slopsquatting.
- A coding model suggests a dependency name.
- An attacker predicts or observes that name and publishes a package under it.
- A developer or AI agent adds the dependency to a project.
- The package manager retrieves it, and installation or build-time code may run.
- That code can reach the build worker, credentials, or downstream artifacts, depending on the job’s permissions.
OWASP’s npm guidance illustrates the distinction with the hypothetical name node-fetch-promise alongside the real node-fetch; that example is not a claim that the illustrative name is malicious. A registry 404 can catch a name that remains unavailable. It cannot identify a malicious package that has already been registered. USENIX research likewise cautions that a package’s presence in a public repository is not proof that its contents are trustworthy. OWASP NPM Security Cheat Sheet · USENIX Security 2025 paper
Recommended Free Tools
How this differs from related package risks
- Typosquatting: a person mistypes the name of a known package. Slopsquatting targets plausible names emitted by models, whether or not the developer intended to use an existing package.
- Dependency confusion: a public package competes with an internal package name. Private scopes and internal-only routing help address this registry-resolution risk.
- Maintainer compromise: an attacker changes a package that was previously legitimate. Package identity review alone cannot prevent a trusted maintainer account or release from later being compromised.
These threats meet at the package manager but are not interchangeable; use controls suited to the risk as well as shared controls such as review, isolation, and monitoring. OWASP CICD-SEC-3 · npm: Threats and Mitigations · UK NCSC dependency guidance
#1 Best Overall
What the published hallucination figures mean
Cloud Security Alliance’s April 19, 2026 summary of the USENIX Security 2025 study reports that 440,445 of 2.23 million generated samples (19.7%) contained at least one hallucinated package name. It says the study used 16 code-generating models across Python and JavaScript. The summary also reports averages of 21.7% for the open-source models and 5.2% for the commercial models studied. These are results for the study’s models, prompts, and evaluation setup—not current prevalence estimates for all AI coding tools or a guarantee about either model category today.
The paper’s released Python and JavaScript datasets contain 19,500 coding prompts and 586,000 generated samples. That dataset count has a different denominator from the summary’s 2.23 million study-generated samples. Neither figure should be generalized to a different model, prompt, or workflow without evidence. Cloud Security Alliance summary, April 19, 2026 · USENIX Security 2025 paper
Build a defense that works before and after installation
1. Gate AI-initiated installation
Do not let an AI agent install arbitrary packages autonomously by default. Require human approval or enforce an organization allowlist before a proposed dependency reaches the package manager. Validate the exact package name in the intended ecosystem and registry, then check that its documented purpose and code fit the application’s need. Give the allowlist an owner and a defined exception process so necessary additions can be reviewed rather than bypassed. OWASP Secure Coding with AI Cheat Sheet
2. Review identity, history, and behavior—not just existence
Inspect the registry record, publisher or maintainer identity, creation date, release and maintainer history, source repository, code, and fit for the requested function. A recent creation date, low download count, or a single maintainer with little history can be a reason to investigate, not proof of malice. A successful registry response establishes that a name exists; it does not establish that the package is legitimate or safe. OWASP NPM Security Cheat Sheet · OWASP Secure Coding with AI Cheat Sheet
3. Make dependency resolution reproducible
Commit the lockfile for the project’s package ecosystem and configure CI to install in its frozen or locked mode. Review manifest and lockfile changes through the normal code-review process. Prefer approved, pinned versions over floating to the latest release, and use package-manager integrity data or explicit hashes where the ecosystem and workflow support them. These measures make the selected artifact more predictable and unexpected changes easier to spot; they do not prove that a dependency was appropriate or benign when approved. OWASP CICD-SEC-3 · OWASP Secure Coding with AI Cheat Sheet
4. Control where packages come from
Configure developer machines and CI to fetch third-party packages through an internal proxy or curated repository that can apply policy and log downloads. Route private scopes exclusively to the internal registry to reduce dependency-confusion exposure. Where appropriate, commit repository-local package-manager configuration so a machine-level setting cannot silently alter resolution. Do not publish internal package names in public registries. A proxy centralizes enforcement; it does not make every package it serves safe without review and policy. OWASP CICD-SEC-3 · npm: Threats and Mitigations
5. Limit what install-time code can reach
Package installation can run lifecycle scripts, so isolate installation and build steps in disposable environments. Withhold signing keys, deployment tokens, and unrelated secrets from dependency-install stages; restrict network egress and job permissions to what the task requires. If compromise is suspected, rotate credentials the affected job could access. Isolation reduces potential impact but cannot guarantee that malicious code will do no harm. OWASP CICD-SEC-3 · UK NCSC dependency guidance
6. Detect changes and prepare to respond
Review dependency diffs and unexpected package additions. Monitor CI activity, network traffic, and credential use, and run dependency scanning for known vulnerabilities or malicious packages. If a package is suspect, have a path to quarantine the affected package or version, rebuild from a known-good lockfile, and rotate exposed credentials. Scanners can flag items covered by their data or detection logic, but a newly published package may not yet have a signature; scanning complements rather than replaces pre-install review and isolation. UK NCSC dependency guidance · OWASP Secure Coding with AI Cheat Sheet · OWASP CICD-SEC-3
Best Value
What each control can—and cannot—establish
| Control | What it helps establish or reduce | What it does not establish |
|---|---|---|
| Registry existence lookup | Whether a name is currently present in the target registry | That a registered package is legitimate or safe |
| Publisher, history, and code review | Potentially suspicious identity, recency, history, or mismatch signals | That future releases or transitive dependencies will stay benign |
| Allowlist or human approval | Whether a proposed name can be added without review | That an already-approved dependency is uncompromised |
| Lockfile and integrity check | Reproducibility and, where supported, detection of unexpected artifact changes | That the selected dependency was appropriate or non-malicious when approved |
| Internal proxy and scoped routing | Centralized policy and fewer unsafe resolution paths, including some dependency-confusion exposure | That every package served by the proxy is safe without review and policy |
| Isolation and least privilege | Limits on secrets and systems reachable by install-time code | That malicious code cannot run or cause harm |
| Vulnerability or malware scanning | Detection of issues represented in the tool’s data or detection logic | That a newly published or previously unknown package is clean |
Use the controls as layers: pre-install review evaluates whether a dependency belongs; lockfiles and integrity checks constrain what gets selected; registry policy governs resolution; isolation limits damage if a gate fails; and monitoring supports detection and response. No one layer substitutes for the others. USENIX Security 2025 paper · OWASP Secure Coding with AI Cheat Sheet · OWASP CICD-SEC-3 · UK NCSC dependency guidance
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
