Auditing Yarn Dependencies: A Guide to yarn audit and yarn npm audit

If you use Yarn, the first thing to get straight is which Yarn you use — because the audit command changed between major versions, and running the wrong one silently gives you nothing. Yarn Classic (v1) and Yarn Berry (v2, v3, v4) resolve the same JavaScript ecosystem but ship different CLIs, different lockfile formats, and different audit tooling. A team that migrated to Berry but kept a yarn audit step in CI may have been running a no-op for months. Let us fix that.

Which command for which Yarn

Check your version first:

yarn --version

Yarn Classic (1.x) has a built-in yarn audit that reads yarn.lock, submits the resolved dependency tree to the npm registry audit endpoint, and reports vulnerabilities from the GitHub Advisory Database across your full transitive graph:

yarn audit
yarn audit --level high
yarn audit --groups dependencies

--level sets the severity floor and --groups dependencies excludes dev dependencies from the report.

Yarn Berry (2.x and later) moved auditing into the npm plugin namespace. The command is yarn npm audit, and it is richer than Classic's:

yarn npm audit
yarn npm audit --all --recursive
yarn npm audit --severity high --environment production

Here --all audits every workspace in a monorepo, --recursive walks transitive dependencies, --severity sets the floor, and --environment production scopes to what actually ships. For CI, both variants can emit JSON — Berry with --json — for a downstream gate.

Enforcing fixes with resolutions

Neither yarn audit nor yarn npm audit applies fixes on its own — they report. The Yarn-native way to force a vulnerable transitive package to a safe version, even when an intermediate dependency requests the bad one, is the resolutions field in package.json:

{
  "resolutions": {
    "vulnerable-package": "^2.3.1",
    "some-dep/nested-vulnerable-package": "1.4.0"
  }
}

After editing, re-install so the lockfile updates:

yarn install

resolutions is the primary lever for transitive remediation in Yarn, and it works in both Classic and Berry. Use it deliberately — pinning a nested package to a version its parent did not expect can occasionally cause incompatibilities, so re-run your tests.

A word on monorepos and workspaces

Yarn's popularity in large monorepos is exactly where the audit story gets tricky. A single repository might contain dozens of workspaces, each with its own dependency subset, all sharing one root lockfile. In Yarn Berry, yarn npm audit --all --recursive is what actually walks every workspace and its transitive tree — omit --all and you audit only the workspace you happen to be standing in, which in a large repo means most of your code goes unscanned. Get this wrong and your CI reports green while entire packages sit unaudited. It is also worth remembering that a shared transitive package with a vulnerability affects every workspace that resolves it, so a single resolutions entry at the root can often remediate a finding across the whole repository at once — one of the few places where Yarn's centralized resolution genuinely works in your favor.

The limits of yarn audit

• Presence, not reachability. Both variants report that a vulnerable version is in the tree. Neither analyzes whether your code reaches the vulnerable function, so unreachable findings crowd the report alongside genuine risks.
• Advisory latency. Auditing against the advisory database means malicious just-published packages, typosquats, and dependency-confusion attacks are invisible until an advisory lands.
• Dev-dependency noise. Build tooling drags in vast transitive trees; without scoping to production you drown real findings in laptop-only ones.
• No policy or memory. Each run is a snapshot — no SLA tracking, no shared accepted-risk record with an expiry, no consolidated view across the workspaces of a large monorepo.

Going further

Keep the correct yarn audit or yarn npm audit as your fast local and CI gate. Then layer continuous analysis for what it cannot see. Safeguard's software composition analysis engine reads the same yarn.lock — Classic or Berry — and adds call-graph reachability, so a critical CVE in a code path your app never invokes ranks below a medium one sitting in your request handler. In a monorepo, that per-workspace reachability is the difference between a triage queue in the hundreds and a shortlist you can act on.

Developers keep Yarn's fast feedback loop through the Safeguard CLI, which runs the same analysis in the terminal and in CI with policy enforced centrally. When a safe fix exists, the autonomous auto-fix workflow opens a tested pull request that applies the upgrade — including the resolutions pins needed for transitive fixes — so remediation is a review rather than an investigation.

Comparing your options against a commercial scanner? The Safeguard vs Snyk comparison lays out how reachability and autonomous remediation change the workflow for JavaScript monorepos.

Yarn audit quick reference

Bottom line: confirm your Yarn version, run the matching audit command as a required CI gate scoped to production severity, use resolutions to pin unsafe transitive packages, and layer reachability-aware continuous scanning so your team fixes what is exploitable — not merely what is present.

See your Yarn workspace dependencies ranked by real exploitability — start free or read the documentation.