Allow a configurable vuln level to make `npm audit` fail

cli
registry
security

(Lenny Martin) #1

This code here - https://github.com/npm/npm/blob/latest/lib/audit.js#L255-L260 - makes npm audit exit with a non-zero exit code if there are any vulnerabilities found.

We’d like to be able to use npm audit in our CI deployment pipeline, but at the moment this makes it unfeasible since it requires us to fix all low impact vulnerabilities. We’d like to be able to configure this to be able to “pass” if only low or moderate vulnerabilities are found, and fail if high or critical level vulns are detected.

A flag like --audit-level high would be super useful for this use case.


(Lenny Martin) #2

I opted for the JFPRI approach - https://github.com/npm/npm/pull/20992


(Adam Baldwin) #3

The predecessor to npm audit,nsp` did this with filter and threshold options. We had this discussion internally before we released npm audit and while I do think this control and functionality is important to have but I’m not sure about implementation details.

Given some product plans I think we would want to pass along the desire to only fail on a certain severity level to the backend api and let it only return the results that are desired. I thikn that could also have the side effect of make things faster as the backend has to do a lot of work so those modifiers could help.


(Lenny Martin) #4

That’s fair, I was thinking as I wrote it that it could/should possibly also impact the reporting and fixing of vulns if set, but I wanted to avoid going down that road (as alluded to in my PR linked above) while it was still speculative.

Given your product plans, and my possibly half-baked PR, do you think it is worth me documenting and testing what I have done - as requested - or should I just park it and wait for the good people of npm to implement your product plans in full?


(Rebecca Turner) #5

From the cli project point of view, I would be inclined toward taking your PR, or something very like it, even without registry support. I’ll get with Adam and we can figure out what interface would be comfortably forward compatible.


(Lenny Martin) #6

I’ve updated my PR to include some docs and tests. Hopefully this means it’s now in good enough shape for you to use it as you desire.


(Adam Baldwin) #7

Quick update. I had a moment to meet with @iarna and we agreed on implementation details so I think a pr can move forward. I’ll let Rebecca take that forward as I’m not sure how pr’s / contributions work now that npm/npm has moved over here.


(Kat Marchán) #8

PRs belong in https://github.com/npm/cli :slight_smile:


(Deven Phillips) #9

Any movement here? I have a client who will not move forward without being able to fail a CI pipeline based on npm audit results.


(Lenny Martin) #10

I opened a PR, which I recall was merged, but I’m not sure what the path from that to release is.

My advice would be to wrap npm audit --json and parse the results. Example (which you are free to use yourself) here: https://github.com/lennym/npm-audit


(Deven Phillips) #11

I actually wrote a tool for this feature. Have a look at it here: https://www.npmjs.com/package/npm-audit-ci-wrapper