← samcollins.blog · software supply chain

Defending against npm attacks is hard

We're seeing more software supply-chain attacks. A set of these can be offset by not installing the latest releases of software. The idea of setting minReleaseAge: 3d to block installing packages fresher than 3 days sounds great, but it turns out it's not easy to achieve.

The following is quick little interactive model Claude built to help me understand the space. We went deeper that what's here, but this was the global birdseye view. Flows and percentages are estimates of my own usage on this machine.

Options and Tradeoffs

The challenge: Package installs don't take one path — e.g. npm, pnpm, bun, curl, GitHub releases, direct tarballs, etc — so there's not a single control to inspect them. Higher-level controls are easier to adopt but easier to bypass. Lower-level controls catch more traffic but create more operational risk.

Interactive model

Package installs can take many paths each with their own controls and tradeoffs

Start with a practical baseline: package-manager registry config plus a policy proxy catches the common npm/bun path. Toggle additional controls to see how much of the remaining traffic they govern. Percentages are illustrative estimates, not telemetry.

Candidate cuts

∞

Long tail / tough edge cases

~1–2%

Even strong software controls usually stop short of 100%. The remaining slice includes admin override, compromised allowlists, pre-cached artifacts, physical or alternate-network paths, and opaque HTTPS downloads where a network control can see the host but not reliably see the package name or version inside the request.

Practical meaning: you can reduce this with signed artifacts, immutable build environments, managed devices, TLS inspection, or tightly controlled networks. On a general-purpose developer machine, it is better treated as a residual risk to make small and visible than a thing ordinary package-manager policy can reliably eliminate.

Takeaway

The point I'm trying to make is this is a surprisingly complex problem with no single solution. Levers exist at different points in the stack, but each with their own gaps in coverage, friction to use, and cost to maintain. None are perfect.

Practically, I do #1 because it's cheap and covers half my exposure. Then I add #3 so I'm at 85% coverage. Adding a local proxy server, with restarts handled by launchd, is actually pretty low friction for me in practice. Even though I mostly use bun, my agents see `npx install` so often I just want the peace of mind that I have npm handled well first. I'll figure out my uv and the rest next.

Beware surface-level advice like "switch to pnpm" or "In your system prompt, forbid installing npm packages released in the last 3 days".