Dependency audit and supply chain

Two failures, opposite directions: shipping a package nobody vetted (install script, typosquatted name, unmaintained transitive dep), and burning a day on advisories that are unreachable in this app. Both come from not asking is this reachable, and what does it cost to remove.

When to activate

• Before npm i <new-package> (or pip/go/cargo/composer equivalent).
• npm audit / Dependabot / Snyk / GitHub alert, or a CI security job failing.
• A PR whose diff includes a lockfile.
• Post-incident: "was this package the way in?"

Adding a dependency — the 60-second vet

1. Do you need it? Platform first: Intl, URL, fetch, crypto.subtle, structuredClone, CSS :has. A 3-line helper beats a transitive tree.
2. Is the name right? Typosquats live one character away (react-domm, lodash.js, crossenv, discord.js-selfbot). Copy the name from the official docs, never from a model's memory or a blog post.
3. Is it alive? Last publish, open-issue trend, maintainer count, downloads. One maintainer + last release three years ago = you are adopting the code.
4. What does it drag in? npm view <pkg> dependencies / npx howfat <pkg> — count transitives and installed size before, not after.
5. Does it run code on install? npm view <pkg> scripts — a postinstall in a utility library is a red flag; install with --ignore-scripts if you must.
6. License compatible? MIT/Apache-2.0/BSD fine for most products; AGPL/SSPL and "source-available" licenses are a legal decision, not a dev one.
7. Pin it. Exact version in package.json (no ^ for anything security- or build-critical), lockfile committed, npm ci in CI — never npm install there.

Triaging an advisory

Run the tool, then think — the count is not the finding.

npm audit --json            # or: pnpm audit / yarn npm audit
npm ls <vulnerable-pkg>     # WHO pulls it in — the fix lives at that edge
pip-audit                   # python
govulncheck ./...           # go: reports reachable symbols, not just versions
cargo audit                 # rust
composer audit              # php

For each advisory answer four questions:

1. Reachable? Is the vulnerable function called on a path that handles untrusted input? A ReDoS in a CLI-only formatter, or a dev-dependency in devDependencies that never ships, is not the same risk as a parser in your request path. govulncheck answers this natively; in JS, grep the call sites.
2. Runtime or build-time? devDependencies still matter (they run on your machine and in CI, with tokens present) but they are not production exposure. Say which one you mean.
3. Fix available? Direct dep → bump and test. Transitive → bump the parent; if the parent is stale, overrides/resolutions (npm/pnpm/yarn) pin the fixed version, with a comment naming the advisory and a follow-up to remove it.
4. No fix? Mitigate and record: disable the feature, validate at the boundary, or replace the package. npm audit fix --force is not a triage step — it happily installs a major bump that breaks the build.

Severity from the advisory is a prior, not a verdict. A "critical" in an unused code path is lower priority than a "moderate" in your auth flow. Order the report by reachability, and say which CVEs you are deliberately accepting and why.

Lockfile review

• Exactly one lockfile per project; two package managers means two dependency graphs and a nondeterministic build.
• A lockfile diff with no package.json change deserves a look: it can be a legitimate transitive bump, or an unrequested major slipping in.
• Check resolved URLs point at the expected registry (not a random tarball or git URL) and integrity hashes are present.
• Review the added names, not just the count — this is where a typosquat or an install-script package arrives.
• Keep .npmrc/registry config in the repo so every machine and CI resolve from the same place.

Keeping it clean

• CI: npm ci + an audit step with an explicit threshold (fail on high in prod deps), plus Dependabot/Renovate grouped weekly so bumps are reviewable.
• Remove what you stopped using: npx depcheck, then delete. Unused packages are attack surface with no upside.
• Prefer fewer, larger, well-maintained dependencies over many micro-packages.
• Record the decision in memory (memory_store, type decision) when you accept a risk or add an override, so the next session does not re-litigate it.

Verification

• Show the tool output before and after (npm audit summary counts, or the specific advisories resolved).
• npm ci from a clean state succeeds and the app builds — a fix that breaks the build is not a fix.
• Tests pass after the bump; for a major bump, name what you exercised.
• npm ls <pkg> proves the vulnerable version is actually gone from the tree, not merely deduped elsewhere.

Reporting

advisory · package (direct/transitive) · reachable? · runtime/dev · action taken. List accepted risks separately with the reason and the mitigation. Never report "0 vulnerabilities" without the command output that says so, and never claim a package is unreachable without naming where you looked.