Software Supply Chain Attacks: Auditing Package Manager Dependencies

Most of the code in a modern application is not written by the in-house team. It is an assembly of hundreds of open-source libraries. A vulnerability in one small library can put the entire system at risk.

Counting the real attack surface

A project that lists twenty direct dependencies usually installs hundreds of packages once transitive dependencies come along. Every package is code running with the application's full privileges, and every maintainer is someone you effectively trust.

That number is rarely seen. Inspecting the full dependency list — not just what is written in the manifest file — often changes how a team views risk.

The three most common ways in

Typosquatting registers package names similar to popular ones and waits for a typo. Account takeover targets maintainers of abandoned libraries, sometimes by simply re-registering an expired email domain. Dependency confusion exploits internal packages whose names are also available in the public registry, so a higher public version installs in place of the internal one.

All three share the same trait: malicious code runs at install time, often through a post-install script, and the target is credentials in the build environment — registry tokens, deployment keys, CI environment variables.

Locking and checking

The lock file is the first line of defence because it pins the exact versions installed rather than a range that can shift. Make sure it is committed to version control and that the deploy process installs from the lock file rather than resolving dependencies all over again.

Automated vulnerability scanning in the integration pipeline catches packages already known to be compromised. Remember its limits: scanning only knows about vulnerabilities that have been reported, so it offers no protection against a package that was just compromised.

Limiting the damage that is possible

Because prevention is never perfect, damage limitation becomes the decisive layer. Disable post-install scripts where you can. Run dependency installs in an environment with no access to production credentials.

Apply least privilege to tokens: a deployment token does not need write access to the registry, and a CI token does not need access to the production database. A successful supply chain attack on a well-restricted environment ends as an annoying incident, not a devastating breach.