When an AI tool needs functionality, it reaches for a package, and with one install you take on all of that package's code, its own dependencies, and the trust of everyone who can publish to it. Modern apps end up with hundreds of these, most of them never chosen by you on purpose. That is the software supply chain, and it is a real part of your app's security surface even though none of the code is yours.
Why a dependency is a security risk
A package runs with the same access your code has: it can read your environment variables, make network requests, and touch the filesystem. So a vulnerability in a dependency is a vulnerability in your app, and a compromised or malicious maintainer can push an update that runs inside it. You are trusting the whole chain, and AI tools grow that chain quickly because installing a package is the fastest way to make a feature work.
Want to see exactly what Prbl flags? Watch it scan a demo app, no repo or account needed.
See a live scan →The AI-specific twist: packages that shouldn't exist
Two risks are worth knowing by name. Typosquatting is a malicious package named to look like a popular one, hoping you install the wrong one. Hallucinated packages are a newer, AI-specific version: the model suggests importing a package that does not actually exist, and an attacker registers that exact name to catch anyone who runs the suggestion. Either way, confirm a package is the real, widely-used one before you add it, rather than trusting the name blindly.
How to manage it
- Audit regularly. Run
npm audit(or your manager's equivalent) to check installed versions against known vulnerabilities, and fix or update what it flags. - Turn on automated alerts. Enable your host's dependency scanning, such as GitHub Dependabot, so you are told when a new vulnerability appears in something you already use.
- Keep dependencies current. Most fixes ship as a newer version, so staying reasonably up to date is most of the battle.
- Add fewer, on purpose. Before installing, ask whether you need it, and prefer widely-used, maintained packages over obscure ones.
This sits alongside the code-level checks in a full review; the habit of looking at what a change actually pulls in is part of reviewing AI-generated code before you merge.
Frequently asked questions
Why is a dependency a security risk?
Because you run its code with the same privileges as your own. A dependency can read your environment variables, make network calls, and access your filesystem. If it has a vulnerability, your app has that vulnerability. If its maintainer is compromised or malicious, a bad update can run in your app. You are trusting not just the package but everyone who can publish to it, including its own dependencies.
What is a typosquatted or hallucinated package?
Typosquatting is when an attacker publishes a malicious package with a name close to a popular one, hoping you install the wrong one. A related risk with AI tools is a hallucinated package: the model suggests importing a package that does not exist, and an attacker registers that exact name to catch anyone who installs the suggestion. Both mean you should confirm a package is the real, widely-used one before adding it.
How do I find vulnerable dependencies?
Run your package manager's audit command, npm audit or the equivalent, which checks your installed versions against known vulnerability databases and lists what to update. Enable your host's automated dependency alerts too, such as GitHub Dependabot, so you are told when a new vulnerability is found in something you already use. Then keep dependencies updated, since most fixes ship as a newer version.
Should I just install fewer packages?
Fewer, well-chosen dependencies is genuinely safer, because every package is more code you did not write and more maintainers you are trusting. Before adding one, ask whether you need it or could write the small piece yourself, and prefer widely-used, actively-maintained packages over obscure ones. AI tools tend to reach for a package quickly; a moment of judgment about whether it belongs pays off.
Start with the code you own
Dependency scanning covers the packages; a code scan covers what your own code does with them, the exposed keys, missing checks, and insecure patterns that live in the parts you wrote. Run a free scan on your app, then keep your dependencies audited alongside it.