npm audit reports a vulnerable package you never chose: fix the parent before you reach for force

Read the report as a path

An audit report for an npm project often names a package you have never added. That package arrives through a chain of dependencies, and the report shows the chain. The npm documentation also describes meta-vulnerabilities: a package that is vulnerable only because it depends on a vulnerable version of another package. Start by writing down, for each finding, the vulnerable package, the version that fixes it, the direct dependency at the top of the chain and whether it is a production or development dependency. The audit sends a description of your dependency tree to the registry and needs a lockfile, and without one the results may differ from run to run, so audit the same lockfile you deploy.

• Group findings by the direct dependency that pulls them in; one update can clear several.
• Note which findings have no fixed version at all. An update cannot clear those.

Apply fixes in order of safety

The safest fix stays within the version ranges you already declare. npm audit fix does that by default, and it needs a full install internally, so it respects your installer settings. Some findings cannot be fixed automatically and need a person to look. Next, update the direct dependency at the top of the chain to a release that depends on a fixed version. Only then consider an override, which replaces a package version anywhere in the tree, or only beneath a named parent. Overrides are read from the root package.json only, and overriding a package you depend on directly needs a matching spec or npm reports EOVERRIDE. Treat an override as a narrow, listed, temporary pin to remove once its parent is updated.

• Run the tests after each group of changes, not once at the end.
• Write down every override with the finding it addresses and the condition for removing it.

Force is a decision, not a fix

The documentation says audit fix with --force installs modules outside your stated ranges, including semver-major updates, and strongly advises against it unless you know what you want. A major release can change behaviour your tests do not cover. So a forced update needs the release notes read, a plan for what could break and a person who accepts that risk. If a finding can be cleared only by a major upgrade of a framework or runtime, that is an upgrade job with its own tests, not a vulnerability fix. Do not let a green audit become the goal if the application no longer behaves as before.

• List each major change separately, with the finding it fixes and the test that shows behaviour is unchanged.
• Defer a major jump in writing, with the reason, when the tests cannot show it is safe.

Scope the audit honestly, and how the paid job is accepted

The audit level changes the exit code and does not filter the report, so choose a threshold deliberately and state it. Omitting development dependencies narrows the audit to what you ship; development tools still run on your machines and in CI, so decide that on purpose. A clean audit says that known advisories for the installed packages are cleared at the threshold. It does not say that the application is secure. The dependency update job fixes the findings of one named scanner at one agreed severity on one branch. Acceptance is the scanner output before and after, the same test results as before, a change list that labels each package as a direct update, a parent update or an override, and a list of everything left with its reason. It is not a penetration test or a compliance certification.