[FEATURE] module creators should be able to whitelist specific npm audit advisories of their dependencies

[boutell]

Motivation

A module may depend on another module which has a "high" rated vulnerability, but one which is only relevant if the module requiring it actually utilizes certain functionality or exposes the ability for a nonprogrammer to do so. In some cases a patched version of the other module may not be available, or may not be available without a significant bc break, and there is no actual vulnerability due to the lack of an exploit path.

Example

The apostrophe module depends on the 2.x series of the mongodb module. The 2.x series of the mongodb module has a vulnerability such that the code can crash if a bad collection name is passed. However, like most applications (though not all), apostrophe does not allow end users to pass a collection name at any point. Thus it is not vulnerable.

Updating to the 3.x series of the mongodb module involves significant bc breaks and may not be practical in the short term.

How

Current Behavior

There is no way to whitelist a specific vulnerability in dependency X as not being relevant in the package.json of module Y.

Desired Behavior

In package.json:

"npmAudit": {
  "safeList": {
    "mongodb": {
      "1203": "ability to pass a collection name is never exposed to the user"
    }
  }
}

The provision for a justification allows for a flag to npm audit to display the details of whitelisted advisories.

Hiding information from the developer is not the goal. I would propose that when only whitelisted advisories are present, npm audit exit with a status of 0, but produce an "Info" level message that n whitelisted advisories were present, offering a flag to display them in detail along with the justifications provided.

References

npm/npm#20565

[ljharb]

With the majority of CVEs being false positives (I see you, regex catastrophic backtracking and prototype pollution), this would be super helpful.

It needn't even be in package.json; perhaps just UI on npmjs.com?

[boutell]

Minor edit made: call the main property npmAudit (because other auditing tools may exist), and call the list of false positives safeList to be more explicit.

[LucaVazz]

I'd also be very interested in the realization of this proposal.

Perhaps it can be sped up as a potential implementation is already avaialble at npm/npm-audit-report#26?

[wesleytodd]

This would really help the Express team manage security voulns. We have been hit many times by not being able to control this story and it causing a huge issue.

That said, there are many cases where a maintainer has an incentive to cover up the vouln and a bad actor can suppress issues maliciously. So we just need to be careful.

[drswobodziczka]

+100 for the feature. It was extremely easy to suppress false positives/not solved vulnerabilities with NSP, now the only solutions (in case of dependency authors are NOT willing to fix) are:

• switch to "another lib", which can be very problematic in case of efforts OR they may be not such "another lib"
• switch OFF npm audit
• switch OFF npm

No from above may be acceptable.. Any update about the plan?

[ruyadorno]

would love to hear your thoughts on this @evilpacket