Every npm Install Is a Security Decision
Before installing an npm package, use these practical checks to reduce supply-chain risk in a client website or web application.
npm install looks like a trivial gesture. It's actually a trust decision - you receive and run code written by a stranger, directly on your machine or in your production build. Attacks through compromised packages (hijacked maintainer accounts, typosquatting, infected transitive dependencies) are no longer a rare occurrence.
For client projects, here are a few simple rules we apply:
We check who maintains the package
A package with a single maintainer, no recent activity, used by a critical project - that's a risk signal. We prefer packages with several active contributors or backed by a company or organization.
We look at the number of transitive dependencies
A small package that pulls in 40 indirect dependencies increases the attack surface. Sometimes it's worth writing the 20 lines of code yourself instead of installing a package for a single function.
npm audit isn't enough, but it's a first filter
We run audit on every major npm install and treat "high" and "critical" vulnerabilities as blockers, not suggestions.
The lock file is mandatory, not optional
package-lock.json always goes into git. Without it, every install can resolve slightly different versions of transitive dependencies - including one that turned out to be compromised in the meantime.
We update often, in small batches
One major update a year is riskier than small, frequent updates you can test and review quickly. Outdated dependencies are just as risky as insecure ones - many vulnerabilities get fixed by a simple version bump that never happened.
None of this is sophisticated. But applied consistently, it eliminates most of the risk - and the rest is what npm audit and continuous monitoring are for.
This is also part of how Legacies approaches client work. A useful business application is not only the interface someone sees on launch day. It needs a build process and dependency set that another developer can inspect, update, and trust months later.