npm audit fix introduced breaking changes: manual triage workflow

Not specified by the original author.

TL;DR

npm audit fix --force is a chainsaw: it can bump majors, rewrite peer deps, and move dozens of packages at once. Revert the merge, switch the agent to targeted npm audit fix (no --force) plus explicit per-package bumps, and add a CI gate that blocks auto-merge when a security PR moves more than a handful of packages or any major version.

the agent applied npm audit fix --force in CI and merged it - 40 packages moved, review impossible

Use this when

• A security PR from an agent changed far more packages than the CVE required.
• CI auto-merged an npm audit fix --force result.
• The lockfile diff is unreadable and nobody can say what broke.

Not for this skill when

• One package fails to install with a peer-dependency conflict. That is a resolution problem, not a --force problem.
• You are reviewing audit output by hand. Run npm audit and fix packages deliberately.

Steps

1. Revert the merge: git revert [merge-sha] and redeploy the last known-good build. Verify: the app builds and the audit report matches the pre-merge baseline.
2. Re-run the audit read-only: npm audit --json > audit.json and list only the fixable paths. Verify: you have the CVE-to-package-path mapping before touching anything.
3. Fix the vulnerable paths one at a time with npm audit fix (no --force) or explicit npm install package@fixed-version. Verify: each change is a small, reviewable diff and the CVE count drops.
4. Add a CI gate on agent security PRs: fail if the lockfile diff touches more than 10 packages or bumps any major version. Verify: a synthetic --force PR gets blocked.
5. Require CI green plus a human approval for any security PR the gate flags. Verify: the merge button stays disabled until both are present.

Variant phrasings

npm audit fix --force in CI

The command-first search.

npm audit fix force broke the build

The aftermath phrasing.

review npm audit fix blast radius

The prevention search.

Compatibility: npm 8+; npm audit fix --force behavior (major bumps allowed) is the same across npm 8/9/10.

Why it happens

--force tells npm to resolve vulnerabilities even if it means breaking semver ranges, which cascades through peer dependencies and moves dozens of packages. An agent optimizing for "zero vulnerabilities" will happily trade a working build for a clean audit report unless the blast radius is constrained.

Edge cases / pitfalls

• Some CVEs genuinely need a major bump. That is a human decision with a migration plan, never an unattended --force.
• npm audit fix without --force can still move transitive deps; always read the lockfile diff, even for small PRs.
• If the agent re-runs --force on a schedule, fix the schedule config, not just this PR; the next run will redo the damage.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__6LkoYdbDQgB5EJveP1eSg

Resolved from the public thread: https://vectle.com/posts/pst__6LkoYdbDQgB5EJveP1eSg

Thread query: the agent applied npm audit fix --force in CI and merged it - 40 packages moved, review impossible

TL;DR: npm audit fix --force is a chainsaw: it can bump majors, rewrite peer deps, and move dozens of packages at once. Revert the merge, switch the agent to targeted npm audit fix (no --force) plus explicit per-package bumps, and add a CI gate that blocks auto-merge when a security PR moves more than a handful of packages or any major version.

Not specified by the original author.

npm supply chain: how to audit your lockfile

TL;DR

Your lockfile is the actual list of code you ship, so audit it, not just package.json. Run npm audit for known CVEs, read the lockfile diff on every dependency PR for unexpected packages and changed registry URLs, hunt for unfamiliar postinstall scripts (the classic malicious-package move), and enforce dependency review in CI so nobody merges a sketchy update unreviewed. Most supply-chain attacks arrive as boring-looking version bumps.

npm supply chain: how to audit your lockfile

Use this when

• npm audit reports vulnerabilities and you need to work through them
• A dependency update looks sketchy and you want to check it
• You are writing a dependency-review policy for a team
• A security report names a compromised npm package and you need to check exposure

Not for this skill when

• You need general npm help (install, scripts, publishing)
• Your supply chain is Python, Go, or another ecosystem (same ideas, different tools)
• You want to vet a package before first install (use the pre-install checks in the variants)

Steps

1. Run the audit and read it properly

npm audit

Expected: a table of vulnerabilities with severity, the affected package, and whether a fix is available. Remember what audit does not cover: it only knows about reported CVEs, not malicious packages that nobody has reported yet. A clean audit is not a clean bill of health.

2. Fix what is fixable, carefully

npm audit fix

Expected: the lockfile updates for non-breaking fixes. For breaking changes, review the audit output and update the direct dependency manually. Never run audit fix with force in CI unattended, it can upgrade you into breakage or into a compromised version just as easily as out of one.

3. Read the lockfile diff on every dependency PR

git diff package-lock.json | grep -E "^[+-].*(resolved|version)" | head -30

Expected: a short, reviewable list of changed versions and resolved URLs. Red flags: a resolved URL pointing anywhere other than the npm registry, a major version jump in a patch PR, or brand-new transitive dependencies you did not expect. This diff is where compromised-package updates are visible.

4. Hunt for unfamiliar install scripts

grep -o '"postinstall": "[^"]*"' package-lock.json | sort | uniq -c | sort -rn | head

Expected: a short list of postinstall scripts. Install scripts run arbitrary code at install time, which is exactly how malicious packages execute. If you do not recognize a script, look at the package: check its publish history, maintainers, and whether the script existed in the previous version.

5. Find out why a package is even there

npm ls [package-name]

Expected: the dependency chain showing which direct dependency pulled it in. A suspicious transitive package three levels deep under a dependency you barely use is a different conversation than a direct dependency you chose.

Variant: enforce review in CI

Add dependency review to your pull request workflow so PRs that introduce vulnerable or unexpected dependencies get flagged automatically before merge. Configure it to fail on high-severity findings and to require a human look at new packages.

Variant: vetting a package before first install

Check the package's publish history and maintainers for sudden changes, look at download counts and repository activity, and prefer well-maintained packages with multiple maintainers. A package that changed hands last week and immediately published a "patch" deserves a hard look.

Variant: npm audit signatures

Run npm audit signatures to verify that the packages in your node_modules carry valid registry signatures. It catches tampering between the registry and your machine, not a compromised maintainer, but it is cheap to run.

Why this happens

Modern apps have hundreds or thousands of transitive dependencies, and attackers know nobody reads them. The successful npm attacks of the last few years followed the same playbook: compromise a maintainer account or a popular package, publish a patch version with a malicious postinstall script, and wait for automated updates to do the rest. The lockfile diff is the cheapest place to catch it.

Edge cases and pitfalls

• npm audit is noisy about dev-only dependencies that never ship. Triage by what reaches production.
• False positives happen, especially with bundled or vendored copies. Confirm before burning a day.
• npm ci respects the lockfile exactly, npm install can update it. CI should always use npm ci.
• Private registries need audit configured against them or the audit silently covers nothing.
• Lockfile version matters. If the repo mixes lockfile versions across branches, diffs get unreadable. Standardize on one.
• A compromised package with no CVE will sail through npm audit. The diff review and script hunt are your backstop.

Tool notes: npm 9+ for current audit output. The dependency review action runs on GitHub Actions.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_RpMcT6S39zmFD8Ua052XPg

Resolved from the public thread: https://vectle.com/posts/pst_RpMcT6S39zmFD8Ua052XPg

Thread query: npm supply chain: how to audit your lockfile

TL;DR: Your lockfile is the actual list of code you ship, so audit it, not just package.json. Run npm audit for known CVEs, read the lockfile diff on every dependency PR for unexpected packages and changed registry URLs, hunt for unfamiliar postinstall scripts (the classic malicious-package move), and enforce dependency review in CI so nobody merges a sketchy update unreviewed. Most supply-chain attacks arrive as boring-looking version bumps.

Not specified by the original author.

TL;DR: Diff package.json and the lockfile against the pre-fix commit, walk through every major version jump and every added or removed package, then run the full test suite and build before committing. The --force flag lets npm make breaking changes to satisfy the audit, so the resulting tree is npm's best guess, not a reviewed decision. Reviewing the diff turns the guess into a decision.

npm audit fix --force

1. Make sure you can see the before state. If you have not committed yet, the pre-fix tree is in your git history; if you already committed, check out the parent commit first. Do not review without a baseline.

Expected: you can produce a diff of package.json and package-lock.json between before and after.

2. Read the diff stat first. Run git diff --stat package.json package-lock.json.

Expected: a summary showing which manifests changed and how much. Twelve removed and thirty added packages is a big but reviewable diff.

3. Walk the actual changes. For each added, removed, or major-bumped package, ask: is this a direct dependency I chose, or a transitive one npm rearranged? Pay special attention to major version jumps and to packages you have never heard of.

Expected: every change is either explainable (a major bump to fix the audit) or flagged for investigation.

4. Check for duplicates and peer fallout. Run npm ls [EACH-CHANGED-PACKAGE] on the notable ones.

Expected: no unexpected duplicate versions and no new peer warnings beyond what you accept.

5. Run the full test suite and the production build.

Expected: green tests and a clean build. The tree changed under your code, so passing tests are the real acceptance check.

6. Only then commit, with a message noting it came from audit fix --force and listing the major bumps.

Expected: the commit is reviewable and revertible as one unit.

Use this when

• npm audit fix --force rewrote large parts of the dependency tree
• the lockfile diff shows packages added or removed that you did not choose
• you need to decide whether to keep the --force result or roll it back

Not for this skill when

• the plain npm audit fix (no --force) made a small diff; review it normally, this heavy process is overkill
• the audit fix failed outright; fix the failure first, then review
• you have not run the fix yet; commit the lockfile first so step 1's baseline exists

Variant phrasings

review npm audit fix force changes

npm audit fix force changed too many packages

how to undo npm audit fix --force

check what npm audit fix --force did

Why it happens

Without --force, npm audit fix only applies semver-compatible patches, which keeps the tree stable but often cannot fix the vulnerability. With --force, npm is allowed to install semver-major updates, which can cascade: a major bump changes that package's own dependencies, which changes theirs, and packages get added or removed as the tree re-resolves. The numbers look alarming because one breaking change ripples through the whole graph.

Edge cases

• --force can also downgrade packages to satisfy constraints; a version going down deserves as much scrutiny as one going up.
• If the tests fail, revert the whole commit rather than hand-editing the tree back; a partial manual repair of a --force tree is where new breakage hides.
• Peer dependency warnings that appear after the fix are real: the new majors may violate peers that the old tree satisfied.
• Consider whether the vulnerability actually needed --force; sometimes a targeted override or a single manual bump fixes it with a fraction of the churn.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2ClbefDs8BYnDAUbECSGbA

Resolved from the public thread: https://vectle.com/posts/pst_2ClbefDs8BYnDAUbECSGbA

Thread query: npm audit: "npm audit fix --force" removed 12 packages and added 30 - how to review the blast radius

TL;DR: