The package you did not mean to install

A typical web application pulls in hundreds of open source packages, most of them indirectly. Each one is code written by someone you have never met, running with the same permissions as your own. Most of the time that is fine. Open source is one of the best things to happen to software.

But public package registries are also an attractive place to hide malware, and the techniques are getting more organised.

How malicious packages get in

• Typosquatting. A package named almost exactly like a popular one, one swapped letter away. A tired developer or an AI coding assistant suggests the wrong name, and it installs.
• Dependency confusion. An attacker publishes a public package with the same name as one of your internal packages. A misconfigured build tool prefers the public one.
• Account takeover. A maintainer of a legitimate package has their registry account compromised, and a new version ships with a payload.
• Install scripts. Many ecosystems let packages run code at install time. That code runs on developer laptops and build servers, often with access to credentials.

Pin, lock and review changes

The basics stop a surprising amount.

1. Commit lock files and make CI install exactly what is in them. Nothing should change versions silently during a build.
2. Review dependency changes like code. A pull request that adds a new direct dependency should say why, and someone should glance at the package's age, maintainers and download history.
3. Delay brand-new versions. Many teams now wait a few days before adopting a freshly published release. Most malicious versions are detected and pulled within that window.

Close the confusion gap

If you publish internal packages, make sure your build tools can only fetch them from your private registry. Reserve your internal names or organisation scope on the public registry too, so nobody else can claim them.

Reduce what install scripts can reach

• Disable install scripts by default where your package manager allows it, and enable them only for packages that genuinely need them.
• Run builds in short-lived environments with only the credentials that build needs, not a long-lived server with access to production.
• Never give CI jobs that install third-party code access to deployment secrets in the same step.

Know what you are running

Generate a software bill of materials for each release so that when the next major open source vulnerability lands, you can answer "are we affected?" in minutes rather than days. Pair it with automated alerts for known vulnerable or malicious versions in your dependency tree.

None of this requires stopping developers from using open source. It means treating the moment a new package enters your codebase as a decision worth a few seconds of attention.