Playbook3 sections · 2 min readBy Dezső Mező · Published October 3, 2026.mdSupply chainnpmSecurityCI
The average npm install pulls in hundreds of transitive packages, each a stranger's code with your users' data in reach. You cannot audit them by reading — but you can decide which strangers you run, know exactly what is installed at any moment, and notice quickly when one turns hostile. This is the working set of controls, in the order they pay for themselves.
01Lockfiles are the audit trail
Commit the lockfile and installs become reproducible — the CI builds what you reviewed, not whatever the registry serves today. 'npm install' mutating your tree in CI is the quiet way a dependency version changes under you.
02Scan continuously, not once
CI-time scanners flag known CVEs at every build; weekly Dependabot or Renovate PRs keep the tree from petrifying. Neither removes risk — both turn 'we might be vulnerable somewhere' into a finite, reviewable list.
03Fewer, older, better-maintained
The strongest control is choosing fewer dependencies: a package with three maintainers and a weekly release cadence is a different risk from one published last Tuesday. For anything that touches money, auth or customer data, writing the fifty lines is often the cheapest option on the table.
What to take away
- Commit the lockfile — CI builds what you reviewed.
- CVE scanning in CI plus weekly update PRs.
- Prefer fewer, older, maintained packages.
- For money, auth and customer data, the fifty lines are cheaper than a dependency.
More from the lab
Browse all entries
Prompt injection in production agents
AI security self-audit
MCP servers in production, not in the demo
Prompts are code: eval them like code
Want this looked at on your own system?Start a conversation
