Tags: web-dev concept

Supply Chain Risk

Date: 2026-08-17

---

Every dependency is code you execute without reading, from a person you don’t know, updated without your involvement. The attack doesn’t need to reach your repository — reaching the registry is enough.

---

Supply chain risk is the exposure created by depending on code you didn’t write and can’t practically review.

The scale is the argument. Twelve declared dependencies routinely resolve to over a thousand packages, maintained by hundreds of people, any of whom can publish an update that runs on your machine tonight.

The attack shapes

Compromised maintainer account — credentials phished or reused, a malicious version published under a trusted name. The package is legitimate; the release isn’t.

Maintainer handover — a burnt-out maintainer transfers a popular package to a volunteer who turns out to have other intentions. Genuinely happens, and it’s hard to detect because the transfer is public and looks like good news.

Typosquatting — a package named one character from a popular one, waiting for a mistyped install.

Dependency confusion — a public package published with the same name as your internal private one, where the resolver prefers the public registry.

Install scripts — postinstall runs arbitrary code at install time, from any package in the tree.

Protestware — a maintainer deliberately sabotaging their own package to make a point, which has happened to widely-used packages.

Why install scripts are the sharp edge

{
  "scripts": {
    "postinstall": "node ./scripts/setup.js"
  }
}

This runs on npm install, from any package in the tree, with your user’s permissions — access to your environment variables, your SSH keys, your cloud credentials, your source.

npm install --ignore-scripts

Worth defaulting to in CI, with an explicit allow-list for the few packages that genuinely need them. Most don’t.

What actually reduces the risk

Ordered by return on effort:

• Commit the lockfile and install from it strictly. Pins versions and verifies integrity hashes, so a silently-altered package fails rather than installs — Lockfiles
• Fewer dependencies. The only measure that reduces the surface rather than monitoring it — Dependency Management
• --ignore-scripts in CI, with exceptions listed
• Scope internal packages (@yourcompany/thing) and configure the registry per scope, which closes dependency confusion
• A delay before adopting new versions. Malicious releases are typically caught within days; a 72-hour cooling-off period removes most of the exposure with almost no cost. Renovate and similar support this directly
• Least-privilege CI credentials. The build should not hold a token that can deploy to production and read your customer database
• Audit and triage rather than dismiss — Dependency Management

The delay tactic is underused

Most malicious packages are detected and removed quickly, because a lot of people are watching. The window of exposure is short.

version published
  ↓  0–48h    highest risk
  ↓  72h      most malicious releases
              have been caught
  ↓
you adopt

Configuring automated upgrades to wait three days costs nothing and removes most of the passive exposure. It’s the highest-value single setting in this note.

Provenance and SBOMs

Emerging mechanisms worth knowing by name:

• Provenance attestation — cryptographic proof that a package was built from a specific commit by a specific CI pipeline, rather than uploaded from a laptop
• SBOM (Software Bill of Materials) — a machine-readable inventory of everything in a build, so that when a vulnerability is announced you can answer “are we affected” in seconds rather than days

[CHECK: current registry support for provenance and any SBOM obligations that apply to your sector — both are moving, and regulatory requirements exist in some contexts.]

The SBOM’s practical value is response time. The question after any major advisory is “do we use this, and where”, and most organisations answer it by grepping.

The realistic position

You cannot review a thousand packages, and pretending otherwise wastes effort. What you can do:

REDUCE   fewer dependencies
PIN      lockfile, integrity hashes
DELAY    don't take releases on day zero
CONTAIN  no scripts, least-privilege CI
DETECT   audit, and know what you ship

Containment is the one most often skipped. Assume a compromise will eventually happen and ask what it would reach — a build with production credentials in its environment is a much worse outcome than one without — Secrets Management.