Open-Source Supply Chain Attacks: No Team Is Too Small to Be a Target
Infect a single npm/PyPI package and every project that installs it gets infected too. How supply chain attacks actually happen, and 3 lines of defense.
"I didn't write this code — so how did my service get breached?" — the classic supply-chain-attack question. The problem wasn't in code you wrote. It was in someone else's code you installed.
What a supply chain attack is
Most projects depend on dozens to hundreds of open-source packages (npm, PyPI, RubyGems, and so on). If an attacker infects just one of those packages, every project that installs it gets infected automatically. It's far more efficient than attacking your code directly, which is why this technique has grown sharply over the past few years.
How it actually happens
- Typosquatting: a fake package with a name similar to a popular one (e.g.
lodash→iodash) is uploaded, waiting for someone to install it by mistake - Maintainer account takeover: an attacker hijacks the maintainer account of an aging package and quietly slips malicious code into a new version of an otherwise legitimate package
- Dependency confusion: an attacker publishes a public package with the same name as your company's internal one, tricking your build system into pulling the public (malicious) version instead
In all three cases, infection happens just from running `npm install` like you always do. You didn't do anything unusual.
Why smaller teams are more exposed
Larger companies often run internal registry mirrors and package-approval processes. Solo developers and small teams, on the other hand, usually install a dependency and never look at it again. AI code-generation tools make this worse — they'll often suggest a new package for a needed feature with little to no vetting, widening the exposure surface.
Three lines of defense
- Commit your lockfile and install pinned versions — without
package-lock.json/pnpm-lock.yaml, the same code can install a different version each time. - Automate dependency vulnerability scanning — check regularly, ideally on every deploy, whether you're running a version with a known vulnerability (CVE).
- Skim the diff before bumping a version — especially for packages that recently changed maintainers or have a short history relative to their download count. A quick look before updating prevents most incidents.
A supply chain attack isn't caused by something you did wrong — it's an incident caused by code you trusted turning on you. Which is why the defense has to cover not just "my code," but all the code I depend on.
WhiteHat Code scans your repository's dependencies, flags packages with known vulnerabilities, and shows you the upgrade path. The automated scan is free.