Skip to content

Latest commit

 

History

History
78 lines (48 loc) · 4.72 KB

security-guidelines.md

File metadata and controls

78 lines (48 loc) · 4.72 KB

What

Guidelines for responsible reporting and disclosure of security vulnerabilities.

Why

Defining a process of reporting and disclosing security vulnerabilities helps maintainers protect projects and their users.

Security policy guidelines

Publishing the policy

Each project should document its security policy in an easily accessible place.

The recommended approach is to publish security policy in a GitHub repository.

Here are several alternative ways of publishing security policies:

  1. SECURITY.md or SECURITY file in the root folder of project repository (if hosted outside of GitHub).
  2. Security page on project website, e.g. https://nodejs.org/en/security/.
  3. security.txt file on project website, e.g. https://nodejs.org/.well-known/security.txt.
  4. Security section of the project README file.

A project's public issue tracker should point out that security issues need to be kept private initially. If using GitHub issues, mention in the issue template that there is a separate process for security-sensitive issues. If using a vulnerability rewards program, the public issue tracker advice should make it clear what is in bounds.

Reporting a security issue

Project security policy should describe a process for reporting vulnerabilities. It is strongly encouraged that the reporting process is confidential to allow maintainers to triage and resolve the vulnerability in private before disclosing it to the public.

A common way of reporting vulnerabilities is through a designated email address, e.g. [email protected].

The policy should clearly specify when confidential reporting is not supported and generally available bug tracking system should be used.

Responsible disclosure

Public disclosure should follow release of a patch that addresses a vulnerability.

The recommended approach is to create a maintainer advisory on GitHub.

Here are several alternative ways to disclose a vulnerability:

  1. Report a vulnerability to npm.

Collaboration between maintainers and reporters

The policy should recommend that maintainers and reporters collaborate to ensure the accuracy of the vulnerability report and the security advisory. In particular, information such as:

  1. Severity (e.g. CVSS score)
  2. Category (e.g. CWE category)
  3. Exact package that is vulnerable
  4. Affected versions
  5. Vulnerability impact

should be established in collaboration between maintainers and the reporter.

If possible, the policy should recommend means of communication between all parties working towards responsible disclosure. See Maintainer advisories on GitHub

Releasing security patches

If releasing security patches deviates from the standard package release process, it should be clearly stated in the security policy.

In particular, if package maintainers cannot commit to releasing security patches in a timely fashion, it should be noted explicitly to allow package consumers to make an informed decision about using the package based on their risk tolerance.

Examples

Here are several examples of short and useful security policies that fit different maintainers' needs:

Template Description
Node.js Ecosystem Security WG Template The common security policy that all packages may follow
Express Security Policies and Procedures Supports a customized workflow and the Node.js Ecosystem Security WG reporting vulnerabilities process
Node-RED Security Policy Defines a dedicated security reporting workflow
Fastify Security Policy Adopt the Node.js Ecosystem Security WG reporting vulnerabilities process
Node.js Issue Template Uses issue templates to guide vulnerability reporters away from the public issue tracker.
Google VRP Bounds Explains to security researches what is in bounds for a vulnerability rewards program.