What it is
Modern applications are mostly other people's code. Supply chain failures are everything that can go wrong with that: a dependency with a known vulnerability, a package taken over and republished with malware, a build server that injects something, a base image with a backdoor. The 2025 list broadened the old vulnerable-components category to cover the whole chain, from registry to build to deploy.
It is new at number three because the attacks became routine: typosquatted packages, maintainer account takeovers, and malicious post-install scripts on npm and PyPI are now weekly events rather than headlines.
How it shows up in AI-generated code
AI coding tools added a failure mode that did not exist before: the hallucinated package. A model writes import fastapi_jwt_helper because it sounds right, the package does not exist, and the install fails. Or it did not exist until someone noticed models keep suggesting that name, registered it, and published something that runs on install. This is called slopsquatting, and the same hallucinated names recur across many generations, which makes it worth an attacker's time.
Tools also pin nothing by default and pull the newest version of everything, so a compromised release reaches you immediately. And they reach for a dependency where a few lines of code would do, which widens the surface. Prbl checks imports against the registry to catch the names that do not exist, and the fix guides cover the rest.
Example: An import that was never published
# Generated: plausible name, no such package on PyPI from fastapi_jwt_helper import verify_token # hallucinated
# Use the real, maintained library and pin it in requirements.txt # requirements.txt: PyJWT==2.9.0 import jwt payload = jwt.decode(token, SECRET, algorithms=["HS256"])
Before installing anything a model suggested, open the package page. Check it exists, check who maintains it, check the download count and the publish date. A package created last week with one version is a red flag.
How to find it
- Run a dependency audit: npm audit, pip-audit, or a scanner like Dependabot or Snyk. This is the part the general tools do best.
- For every import an AI tool added, confirm the package exists on the registry and is the one you meant. Prbl rule PRBL-P001 flags imports that resolve to nothing.
- Look for post-install scripts in newly added packages.
- Check that your lockfile is committed and that CI installs from it.
How to fix it
- Pin versions and commit the lockfile. Update deliberately, not on every install.
- Turn on Dependabot or an equivalent so known vulnerabilities reach you as pull requests.
- Verify any package an AI tool introduced before you install it; delete the ones you cannot justify.
- Prefer a few well-maintained dependencies over many small ones.
- Sign and verify build artifacts if you ship anything downstream.
What Prbl checks for this category
Run a free scan on a public repo or a live URL. Findings link to the fix guides below.
Fix guides for this category
Go deeper
Common questions
What is slopsquatting?
Registering a package name that AI models frequently hallucinate, so that the next developer who copies the generated import installs your code. It is typosquatting aimed at models instead of at human typos, and it works because the same wrong names come up again and again.
Does Prbl replace Dependabot or Snyk for dependencies?
No. Prbl's supply chain check is narrow: it catches imports of packages that do not exist. For known vulnerabilities in real dependencies, run Dependabot, Snyk or Socket alongside it. They are good at that and it is free on GitHub.
Why is this new in 2025?
The older category was vulnerable and outdated components. The 2025 list widened it to the whole chain because the incidents that hurt most recently were not old versions; they were maintainer account takeovers, malicious releases and compromised build steps, none of which an outdated-version check would catch.