作为维护者和发布者，如何声明 npm package 中的安全漏洞？

Question

When I find a security vulnerability in one of my own published packages, how can I flag a range of susceptible versions, so that downstream consumers will be notified when they run npm audit ?

Answer 1

Essentially you don't flag a range of susceptible versions per se. Instead you report it/them directly to NPM via the “Report malware” button that can be found on the specific npm package page at www.npmjs.com . The npm Security team then triages the report, and they flag it in the database. Users are then notified accordingly when running the npm audit command.

For further details refer to this post in the npm blog. Whilst the npm blog has been discontinued, AFAIK the process for reporting a security vulnerability is much the same.

Quoted below are the pertinent parts regarding the information that you need to provide to NPM about the vulnerability...

_{Source: https://blog.npmjs.org/post/179430064885/writing-quality-vulnerability-reports.html}

In order for us to make sure reported vulnerabilities are handled rapidly and effectively, we need you, our community, to provide us with actionable, detailed information. Here's some basic do's and don'ts for your security report:

What should be included in a quality security report

• The package name and version where you experienced the vulnerability. Example: marked@1.0.0 or marked@*
• A short description of the vulnerability and its impact. Example : “If a user is able to control input into the function foo then the user is able to execute commands giving the attacker the same access as the user running the application.”
• Details of the environment in which you experienced the vulnerability. Example : “This was found to be exploitable using node.js 6.0.0 on OSX, but was not tested using any other platform or Node.js version.”
• A demonstrable proof of concept or steps to reproduce the same result. This helps the npm Security team efficiently triage the issue (see the example below).
• Any particular references, code snippets, or documents that might help the npm Security team or the maintainer better understand (see the example below).

What should not be reported

• Reports without actionable context are very time-consuming for our team to adequately process. These requests should go to the package maintainer in the form of an issue.
• The output of npm audit - As the npm Security team already knows about these flaws, it's better to reach out to the maintainer directly to update dependency versions.
• General feature requests
• Stack traces or errors without explanation as to what security impact they have.