dependency-supply-chain-review

Run npm audit --json to capture findings non-destructively, then classify each CVE by whether the vulnerable code path is reachable in your project. Check for non-breaking fix versions and use overrides or resolutions for unresolvable transitive dependencies.

Read the package.json scripts field of every dependency and flag postinstall, preinstall, install, or prepare hooks that download binaries, run curl or wget, or modify system files. Legitimate packages like esbuild and puppeteer download binaries but should verify checksums.

No, the audit is read-only and non-destructive. It never runs npm audit fix --force, npm install, or any command that modifies node_modules or the lockfile without explicit user approval.

npm ci fails when the lockfile is out of sync with package.json, guaranteeing reproducible installs, while npm install silently mutates the lockfile between CI runs. A failing npm ci signals a real inconsistency that should be fixed, not suppressed.

Skip it when the project has no third-party dependencies, when the task is auditing application runtime logic unrelated to packages, or when a dedicated scanner like Snyk or Dependabot has already triaged all findings and you only need to implement fixes.

Dependency confusion occurs when an attacker publishes a public package matching your private package name with a higher version, causing npm to prefer it. Prevent it by scoping private registries to your organization namespace in .npmrc and claiming your org scope on the public registry.