Treat the lockfile as code

Supply-chain attacks rarely arrive through code anyone reads. They arrive through a dependency bump in a lockfile nobody opens, or a postinstall script that runs on every developer's machine and every CI runner. This repo's policy is one line:

Treat npm dep and lockfile changes as reviewed code.

The engineering is in how each attack path gets closed.

Every path a dependency can take, and its gate

The lockfile gate, in detail

package-lock.json is staged.

Review lockfile changes before committing:
  - confirm every new/updated package is intentional
  - confirm npm age gates were active for resolution
  - review any new lifecycle scripts in the dependency tree

Detected package version changes:
  - changed <package> <old> -> <new>

If this lockfile change is intentional, commit with:
  …_ALLOW_LOCKFILE_CHANGE=1 git commit ...

1. Diff, don't guessIt compares the lockfile at HEAD with the staged one, entry by entry, and lists what was added, removed or changed.
2. Quiet when nothing external changedChanges that only touch the repo's own workspace packages pass through, so the gate doesn't train people to ignore it.
3. A checklist, not just a blockAge gates (refusing versions published too recently to have been vetted) and new lifecycle scripts are what most attacks rely on, so the hook asks about exactly those.

Agents can't slip a dependency change into an unrelated commit, and neither can humans.

Lists that can't rot

• If an allowlisted install-script package disappears from the tree, the check fails and asks you to remove its entry.
• A nightly npm audit fails on moderate advisories or worse. Accepting one requires naming the package and explaining why it doesn't apply, and the script warns about accepted entries that no longer match.
• The same job runs npm audit signatures to verify registry signatures.
• The curl installer pins every transitive dependency for users; plain npm install -g doesn't, and the README says so.

One dependency has a rule of its own: before updating undici, the HTTP client underneath Node's fetch, read its changelog and check whether anything affects the app.

Harden how this project handles dependency changes.

The idea: treat dependency and lockfile changes as reviewed code. Pin exact versions, install without lifecycle scripts, allow only a short documented list of packages to run install scripts, and block lockfile commits unless someone confirms the change is intentional.

1. Check how dependencies are declared (ranges or exact versions), how CI installs them, and whether install scripts run.
2. Find which dependencies actually have install scripts, and for each say whether it needs them and why.
3. Propose and implement: a check that direct dependencies use exact versions; installs with scripts disabled (for npm, --ignore-scripts) plus an allowlist with a reason per package; and a pre-commit check that stops lockfile commits unless an environment variable confirms them, printing what changed.
4. If there's no scheduled audit, add one that fails on moderate or worse advisories and needs a written reason to accept one.

Before changing CI, show me any dependency that breaks without its install script.