Auditing and fixing vulnerable npm dependencies

WHAT THIS TESTS: Whether you know the practical workflow for finding and remediating known-vulnerable dependencies and understand the trade-offs and limits of automated fixes.

A GOOD ANSWER COVERS: Start by scanning: npm audit (or yarn audit) compares your installed dependency tree, as pinned in the lockfile, against a public advisory database and reports each vulnerability's severity, the affected package, and the dependency path, including transitive dependencies you did not install directly. To remediate, npm audit fix updates vulnerable packages to patched versions that fall within your existing semver ranges, automatically. When the only fix is a breaking major version, npm audit fix --force will install it but may break your app, so you upgrade deliberately, read changelogs, and run your test suite. You should commit package-lock.json so the audit reflects exactly what is deployed, and integrate npm audit into CI (optionally with --audit-level to fail only on high/critical) so regressions are caught on every PR. Complementary tooling like Dependabot, Renovate, or Snyk automates PRs and continuous monitoring.

COMMON WRONG ANSWERS: Running audit fix --force without testing and shipping breaking changes; deleting the lockfile to make warnings disappear; treating every advisory as equally urgent without considering exploitability or whether it is a dev-only dependency; ignoring transitive vulnerabilities because they were not directly installed.

LIKELY FOLLOW-UPS: How do you handle a vulnerability with no available patch (overrides/resolutions, temporary mitigation)? Why might a reported vuln not be exploitable in your usage? How do you prevent audit noise from blocking deploys?

ONE CONCRETE EXAMPLE: CI runs npm audit --audit-level=high; a high-severity advisory in a transitive package appears. npm audit fix patches it within range without a major bump, the test suite passes, the updated lockfile is committed, and the build goes green.