pnpm audit: Node dependency checks explained

What the command does

The audit command built into the pnpm package manager checks a project's resolved dependency tree, transitive packages included, against the advisory data of the npm registry. It reports every installed version that falls in an affected range, together with the range that fixes it.

How DevFlow runs it

The Node scanner runs pnpm audit --json in the task's worktree. The command exits non-zero when it finds vulnerabilities, so DevFlow treats the run as failed only when that exit comes with no output at all.

Like every scanner, the run is bounded by a timeout of 300 seconds by default. That limit matters here, because the check has to reach the registry over the network.

Choosing an id

The JSON output holds an advisories map with one entry per advisory, however many paths in the tree lead to it. For each entry, DevFlow picks one identifier in a fixed order:

1. the GitHub advisory id, a GHSA id;
2. otherwise the first CVE listed;
3. otherwise a fallback built from the numeric id of the entry, in the form PNPM-<n>.

The order means the same flaw usually carries the id that GitHub and other scanners use for it, which keeps findings comparable across ecosystems.

The other fields

DevFlow takes the module name as the package, plus the advisory title and URL. The fixed version comes from the patched_versions field, which is a version range such as >=1.2.3 rather than a single release, so read it as the range that is safe.

Severity comes straight from the label of each entry: critical, high, moderate and low keep their names, and anything unrecognised becomes unknown. The output also carries totals per severity in a metadata block, but DevFlow counts from the entries themselves, so the summary always matches the list.

A worked example

Suppose a task adds a date library to a web app, and the lockfile resolves a transitive dependency with a published advisory. The scan lists that dependency by name, with its GHSA id, the advisory link and the patched range, even though the task never named the package directly. The reviewer finds that named entry in the task's scan report, while the evidence section of the pull request counts the repository's findings by severity.

Where results go

Findings are listed by name in the task's scan report, and the merge evidence section of the pull request counts them by severity for each repository. The recurring vulnerability poll runs the same check on each default branch, every 12 hours by default, and turns each finding into an attention item titled with the advisory id, its title and the repository name.