DEV Community

Rodrigo Oler
Rodrigo Oler

Posted on • Originally published at oler.pages.dev

How to Protect JavaScript Projects Against Supply Chain Attacks

The Axios incident is a useful reminder that npm risk is not abstract.

A practical defense model for JavaScript projects starts with a few boring but effective controls.

The baseline

Use these defaults:

  • pin versions and keep lockfiles committed
  • run npm ci --ignore-scripts in CI
  • review dependency changes like code changes
  • use short-lived credentials where possible
  • rotate secrets after suspicious installs
  • separate build credentials from runtime credentials

That will not eliminate supply chain risk, but it removes a lot of avoidable exposure.

Why this matters

The main mistake teams make is assuming supply-chain risk is just a vulnerability scanning problem.

It is broader than that.

It is a process problem:

  • install policy
  • dependency review
  • secret scope
  • CI isolation
  • incident response

If those pieces do not work together, a malicious package has a much easier time moving through your system.

What to put in CI

At minimum, I would recommend:

npm ci --ignore-scripts
Enter fullscreen mode Exit fullscreen mode

Then add policy around:

  • lockfile diffs
  • minimum release age rules for critical packages
  • package allowlists for sensitive environments
  • alerts for unexpected dependency ownership changes

Tools like Renovate and Dependabot help, but only if you configure them with policy instead of treating them as passive update bots.

Why the Axios case is useful

The Axios incident is not interesting because it was unique.
It is interesting because it was plausible.

The attack worked because it used the same trust paths teams already rely on every day: a popular package, a maintainer account, and an install-time hook.

That is why the best defenses are often boring, repeatable controls.

A practical checklist

Before you ship, check that you can answer these questions:

  • Who reviews dependency changes?
  • Which builds can execute install scripts?
  • Which secrets are present in CI?
  • What happens if a package becomes compromised tomorrow?
  • How fast can you rotate credentials if that happens?

If those answers are fuzzy, that is where to start.


Originally published on my blog.

Top comments (0)