Process on resolving pnpm audit findings

[simhnna]

We're currently using npm pretty much everywhere at my company. I'm exploring pnpm as an alternative.

I'm not sure what the equivalent of npm audit fix is in pnpm. Coming from npm I'm used to being able to update what's needed to remove known security issues. AFAIK there's no single command that accomplishes the same in pnpm.

The closest I got was to

1. pnpm audit --fix to populate overrides,
2. pnpm install to persist changes in lockfile,
3. remove overrides
4. pnpm install
   That way the dependencies that were overridden stay there as long as they comply with all specified version ranges. Remaining audits need to be looked at again

How do others handle that? Just live with the overrides?

[ronjouch]

Agreed. To reformulate OP and try to understand the pnpm status quo: is there a rationale for pnpm audit --fix to only add overrides and to not touch pnpm-lock.yaml (as someone familiar with npm audit fix would expect)?

In the case where I want to fix security issues, what I expect as a package manager user is to update the source of truth defining the tree of packages to use... a.k.a. the lockfile. And so,

1. I want to keep my package.json & pnpm-workspace.yaml untouched! (Since my semver requirements didn’t change)
2. I want to update pnpm-lock.yaml so that patched versions are used (Since it’s the prod source of truth)
3. Finally, to someone who would say “then just nuke & recreate the lockfile”, no I don’t want to wholly “regenerate” the lockfile (this is a separate concern, with more risks), I just want pnpm to selectively update the vulnerable packages in the lockfile.

Am I/we missing something? Is there a benefit to the current behavior of pnpm audit --fix ? Would a new flag pnpm audit --fix-in-lockfile make sense?

[zkochan]

In my experience the fixes to the vulnerabilities are frequently only released for the last major version. As a result, pnpm update -r <vulnerable-dependency-name> doesn't always update all the vulnerable versions.

Usually I do run update first and when that is not enough, I run pnpm audit --fix and pnpm install.

then just nuke & recreate the lockfile

That's not needed, if pnpm update doesn't help, nuking won't help either.

I did not have any knowledge about how npm audit fix worked. We have implemented our solution from scratch independently. If someone wants to improve how this works, I don't have objections. For me it isn't high priority at the moment. I'd rather just improve the docs if that helps.

[ronjouch]

@zkochan thx for listening 🙂

fixes to vulnerabilities are frequently only released for the last major version. As a result, pnpm update -r <vulnerable-dependency-name> doesn't always update all the vulnerable versions.

Agreed. Tangentially, from the perspective of someone used to npm audit fix, my immediate answer to this is: why would I bear the burden to repeatedly (if multiple vulns to patch) individually update vulnerable dependencies by calling pnpm update -r <vulnerable-dep>name> ? I’d like to be able to pnpm audit fix just like I npm audit fix, and the tool (not me!) does the job of performing the minimal set of lockfile security updates, for one or several deps 🙂.

Usually I do run update first and when that is not enough, I run pnpm audit --fix and pnpm install

Okay this confirms what OP says. For now, pnpm audit --fix && pnpm install && git restore pnpm-workspace.yaml kinda is equivalent to npm audit fix in updating the lockfile only (with obvious git caveats).

I did not have any knowledge about how npm audit fix worked. We have implemented our solution from scratch independently. If someone wants to improve how this works, I don't have objections. For me it isn't high priority at the moment. I'd rather just improve the docs if that helps.

👍. A precision requet to you for a future-me-with-enough-time-to-work-on-this, or any motivated passerby: what would be the CLI API you’d expect, given A. existence of pnpm audit --fix and B. existence of npm audit fix ?

• A. In the absence of pnpm audit --fix I would have pushed for pnpm audit fix, but then we’ll have both pnpm audit fix and pnpm audit --fix, very weird IMO
• B. Sooooo... pnpm audit --fix-in-lockfile ?
• C. Or maybe pnpm audit --fix --lockfile-only ?
• D. Something else?

Given the rest of the pnpm CLI API, would you go for B. / C. / D. ? Thanks for pnpm!

[jasonpaulos]

I have some experience using @npmcli/arborist to identify and fix npm dependency vulnerabilities in Dependabot. Having the same level of support for pnpm would be a huge help there.

I've started to implement a similar method of auditing for pnpm in #10322 #10341. Still needs work but I wanted to share since it's relevant to this thread.

[jasonpaulos]

Update: this feature has been included in pnpm v11: https://github.com/pnpm/pnpm/releases/tag/v11.0.0

Usage pnpm audit --fix=update

Docs: https://pnpm.io/cli/audit#--fix

[dafi-dnv]

This still does not have feature parity with npm adit fix and npm audit fix --force. It does not have to, pnpm promises "smarter dependency management".

I did not have any knowledge about how npm audit fix worked. We have implemented our solution from scratch independently.

If you did not checked how others did that already, then it's smarter than what?

update seems to update all dependencies, not just the minimal set. There is update --interactive, first I could select packages to patch, then I have to select packages to update. If the vulnerability is transitive, I must select some unrelated direct dependency to update, because at least one have to be selected to continue. If the vulnerability is direct, then I have to select it for update, again, and sometimes it forces to update to later version, not the previously selected, patched version.

BTW The interactive table has so many columns that it becomes difficult to use unless the terminal is nearly full-screen.

overrides is another feature used by npm, it's confusing that pnpm uses overrides, with different implementation, to patch vulnerabilities. This could silently update transitive dependency to version outside of the dependency range.

Ideally, by default fix would do the smallest set of dependency changes, within existing version ranges, just in the lock file, and it should not bypass minimumReleaseAge. Default fix should be safe and secure. It should clearly show any required dependency updates outside of existing versions ranges and release age and user have to allow those explicitly.

That would make the pnpm audit fix feel smart to me.

This can be done manually, but only for direct dependencies. Run pnpm audit --fix=update -i, cancel, then run pnpm install package@patched.version for each patch you would like to apply.

[IanGraingerGMSL]

Is it just me that expects to update the (much simpler to read!) package.json directly, rather than just the lockfile? I take the point about the semver requirements still being true - but the package.json is actually readable, so it'd be much easier for me to track what's going on if that was updated to show the new top ends of the semvers - the same as would happen if I ran the updates manually with pnpm add package@version - that would also update the lockfile of course.