From d8b7124b5aca16b1fb4df073d3c2c96595edd4ea Mon Sep 17 00:00:00 2001 From: Rifa Achrinza <25147899+achrinza@users.noreply.github.com> Date: Sun, 20 Mar 2022 19:40:42 +0800 Subject: [PATCH] docs: remove Node.js Ecosystem HackerOne program Remove documentation related to the Node.js Ecosystem HackerOne program. see: https://github.com/nodejs/node/pull/42144 Signed-off-by: Rifa Achrinza <25147899+achrinza@users.noreply.github.com> --- processes/responsible_disclosure_template.md | 21 --- processes/third_party_triage_guidelines.md | 51 ------ processes/third_party_vuln_process.md | 156 ------------------ .../third_party_vuln_submit_form_hacker1.md | 54 ------ 4 files changed, 282 deletions(-) delete mode 100644 processes/responsible_disclosure_template.md delete mode 100644 processes/third_party_triage_guidelines.md delete mode 100644 processes/third_party_vuln_process.md delete mode 100644 processes/third_party_vuln_submit_form_hacker1.md diff --git a/processes/responsible_disclosure_template.md b/processes/responsible_disclosure_template.md deleted file mode 100644 index 918967c0c..000000000 --- a/processes/responsible_disclosure_template.md +++ /dev/null @@ -1,21 +0,0 @@ -This project participates in the Responsible Disclosure Policy program for the Node.js Security Ecosystem. - -* [Report a security vulnerability](https://hackerone.com/nodejs-ecosystem) - - -# Responsible Disclosure Policy - -A responsible disclosure policy helps protect the project and its users from security vulnerabilities discovered in the project’s scope by employing a process where vulnerabilities are publicly disclosed after a reasonable time period to allow patching the vulnerability. - -All security bugs are taken seriously and are considered as top priority. -Your efforts to responsibly disclose your findings are appreciated and will be taken into account to acknowledge your contributions. - - -## Reporting a Security Issue - -Any security related issue should be reported to the [Node.js Ecosystem](https://hackerone.com/nodejs-ecosystem -) program hosted on HackerOne which follows the [3rd party responsible disclosure process](https://github.com/nodejs/security-wg/blob/master/processes/third_party_vuln_process.md) set by the Node.js Security WG. - -One may also directly contact the project’s maintainers, but through the HackerOne program the Security WG members will take care of triaging the vulnerability and invite project maintainers to participate in the report. - -As an alternative method, vulnerabilities can also be reported by emailing security-ecosystem@nodejs.org. diff --git a/processes/third_party_triage_guidelines.md b/processes/third_party_triage_guidelines.md deleted file mode 100644 index 244d2bd34..000000000 --- a/processes/third_party_triage_guidelines.md +++ /dev/null @@ -1,51 +0,0 @@ -# Node.js Ecosystem Triage Guidelines - -## Introduction - -The purpose of this document is to bring the Node.js Ecosystem Triage team to a common understanding of how to triage and disclose security vulnerabilities reported through the Node.js third-party modules program hosted on HackerOne (https://hackerone.com/nodejs-ecosystem). - -## Why are guidelines needed? - -The Node.js Ecosystem Triage team consists of volunteers with varying level of time, energy and vulnerability management experience. Documenting best practices and common understanding of core concerns when triaging issues will allow the team to provide more consistent service both for security researchers and package maintainers. - -Guidelines will also be a useful resource in onboarding new triage team members. - -## What counts as a vulnerability? - -HackerOne gives the following definition of a vulnerability: - -``` -A software bug that would allow an attacker to perform an action in violation of an expressed security policy. A bug that enables escalated access or privilege is a vulnerability. Design flaws and failures to adhere to security best practices may qualify as vulnerabilities. (...) -``` - -Any bug that is directly exploitable by attackers is a vulnerability. - -Special case to consider are defects in libraries: if a documented or obvious way to use a library leads to an exploitable vulnerability in the correct and safe calling code, then those defects are also vulnerabilities. Some APIs are unsafe to use and are not vulnerabilities if they are clearly marked this way and if safe alternatives exist. An excellent example of this is dangerouslySetInnerHTML in React. - -## What is an expressed security policy? - -Packages may have different threat models and maintainers may express desired security properties in documentation. In such cases it is important to evaluate the report against those properties. For example: a JSON parsing package may not be designed to handle untrusted schema and requires data sanitization to be performed by the caller. In this case a report that violates these preconditions may not count as a vulnerability. - -## What is the root cause of the vulnerability? - -There are cases where the submitter notices a vulnerability in a parent package but the root cause of the vulnerability can be traced to one of the downstream dependencies. An example of this was an XSS vulnerability in the `serve` package that could be traced to lack of proper HTML escaping in the downstream `serve-handler` package. In cases such as this one, it is important to work with submitter and package maintainers to determine where a vulnerability in question is best remediated. - -## Does package maintainer have to acknowledge the vulnerability? - -If the triage team can contact the maintainer, then getting them to acknowledge the vulnerability before proceeding is strongly encouraged. If it was not possible to make contact, the responsibility for making a decision is on the triage team. - -## Which vulnerabilities need to be disclosed? - -Vulnerabilities that require users of a package to take an action, most often upgrade of the package, need to be publicly disclosed. - -## What about resolution verification? - -Sometimes vulnerability resolutions are partial and do not fully resolve the underlying problem. It is encouraged to facilitate collaboration between the submitter and package maintainer to verify if the resolution is full and does not lead to further security problems. - -# References - -HackerOne Disclosure Guidelines -https://www.hackerone.com/disclosure-guidelines - -CVE Counting Rules -https://drive.google.com/file/d/1edCzKfsds79S6z411EJ5qQa-c6z2Bc4A/view diff --git a/processes/third_party_vuln_process.md b/processes/third_party_vuln_process.md deleted file mode 100644 index 35eaad832..000000000 --- a/processes/third_party_vuln_process.md +++ /dev/null @@ -1,156 +0,0 @@ -# Ecosystem Vulnerability Management - -This document describes the management of vulnerabilities within the Node.js -ecosystem. Vulnerabilities in Node.js core are out of this scope. - -## Definitions - -* package: in this document, a package is a module available for use with Node.js - and hosted on the npmjs.org repository. - -## Reporting vulnerabilities - -Individuals who find potential vulnerabilities in a package are invited -to complete a vulnerability report on the dedicated HackerOne organization: [https://hackerone.com/nodejs-ecosystem](https://hackerone.com/nodejs-ecosystem) - -### Strict measures when reporting vulnerabilities - -It is of the outmost importance that you read carefully and follow these guidelines to ensure the ecosystem as a whole isn't disrupted due to mistakenly reported vulnerabilities: - -* Avoid creating new "informative" reports on HackerOne. Only create new HackerOne reports on a vulnerability if you are absolutely sure this should be tagged as an actual vulnerability. Do not attempt to create a HackerOne report with severity set to none or low in hope that this won't be picked up even if it isn't being PR'ed to the Node.js Security WG advisories. Third-party vendors and individual are tracking any new vulnerabilities reported in HackerOne and will flag them as such for their customers (think about snyk, node audit, source clear). -* HackerOne reports should never be created and triaged by the same person. If you are creating a HackeOne report for a vulnerability that you found, or on behalf of someone else, there should always be a 2nd Security WG member who triages it. If in doubt, invite more Security WG members to help triage the validity of the report. In any case, the report should follow the same process as outlined below of inviting the maintainers to review and accept the vulnerability. - -## Handling vulnerability reports - -When a potential vulnerability is reported, the following actions are taken: - -### Triage - -**Who:** The triage team - -**Delay:** 2 business days - -Within 2 business days, a member of the triage team provides a first answer to the -individual who submitted the potential vulnerability. The possible responses -can be: - -* Acceptance: what was reported is considered as a new vulnerability -* Rejection: what was reported is not considered as a new vulnerability -* Need more information: the triage team needs more information in order to evaluate what was reported. - -Triaging should include updating issue fields: -* Asset - set/create the module affected by the report -* Severity - TBD, currently left empty - -Reference: [HackerOne: Submitting Reports](https://docs.hackerone.com/hackers/submitting-reports.html) - -### Correction follow-up - -**Who:** A member of the triage team - -**Delay:** 45 days - -When a vulnerability is confirmed, a member of the triage team is -designated to follow up on this report. - -With the help of the individual who reported the vulnerability, they contact -the maintainers of the vulnerable package to make them aware of the -vulnerability. The maintainers can be invited as participants to the reported issue. - -With the package maintainer, they define a release date for the publication -of the vulnerability. Ideally, this release date should not happen before -the package has been patched. - -If the maintainers are unreachable, the vulnerability is to be made public -45 days after the triage date. - -The report's vulnerable versions upper limit should be set to: -* `*` if there is no fixed version available by the time of publishing the report. This is mostly in cases where the maintainer hasn't taken part in the triage process. -* the last vulnerable version. For example: `<=1.2.3` if a fix exists in `1.2.4` - -### Publication - -**Who:** A member of the triage team - -**Delay:** 45 days - -Within 45 days after the triage date, the vulnerability must be made public. - -**Severity**: Vulnerability severity is assessed using [CVSS v.3](https://www.first.org/cvss/user-guide). -More information can be found on [HackerOne documentation](https://docs.hackerone.com/hackers/severity.html) - -If a patch is being actively developed by the package maintainer, an additional delay -can be added with the approval of the triage team and the individual who -reported the vulnerability (this is a simple vote where each member of the -triage team and the vulnerability reporter have 1 vote each). - -At this point, a CVE should be requested through the HackerOne platform through -[email](mailto:cve-assign@hackerone.com) that should include the Report ID and a summary. - -The vulnerability is considered as published when a Pull Request adding it -to this repository is opened. - -Within HackerOne, this is handled through a "public disclosure request". - -Reference: [HackerOne: Disclosure](https://docs.hackerone.com/hackers/disclosure.html) - -## Vulnerabilities found outside this process - -Vulnerabilities found and fixed outside this process should be added into -the vulnerability database. This can be done by anyone through a Pull Request on -this repository. - -The vulnerability should include any kind of supporting material such as references, maintainer review or otherwise to confirm the vulnerability report is valid. - -## Use of CVEs and reference - -Every vulnerability disclosed by the triage team through HackerOne must -be assigned a CVE number. - -Vulnerabilities disclosed to this repository without using HackerOne currently cannot be assigned a CVE by the triage team (we are working to resolve this) but may have a CVE number if was assigned by another entity. - -## The triage team - -The triage team is composed of 5 or more members of the security working group. -This team is approved and modified by a vote from the working group. - -They are responsible for the management of this process. - -Each member of the triage team is expected to handle vulnerabilities on a -regular basis. - -Members of this team are required to follow the same NDA and privacy measures -as the [Node.js Security Team](https://github.com/nodejs/security-wg#current-project-team-members). - -### Members - -Members of the security teams should indicate that they accept the privacy -policies by PRing their acceptance to this file: - -* @DanielRuf - Daniel Ruf -* @esarafianou - Eva Sarafianou -* @grnd - Danny Grander -* @karenyavine - Karen Yavine Shemesh -* @lirantal - Liran Tal -* @MarcinHoppe - Marcin Hoppe -* @ronperris - Ron Perris -* @vdeturckheim - Vladimir de Turckheim - -### Emeritus Members - -* @bengl - Bryan English -* @brycebaril - Bryce Baril -* @cjihrig - Colin Ihrig -* @dgonzalez - David Gonzalez -* @elexy - Alex Knol -* @gergelyke - Gergely Nemeth -* @pxlpnk - Andreas Tiefenthaler -* @sam-github - Sam Roberts - -## HackerOne Support Engineers - -Following contacts are officially assigned HackerOne support staff for the Node.js Ecosystem program: - -* Alek Relyea -* Megan Mahowald -* Reed Loden @reedloden diff --git a/processes/third_party_vuln_submit_form_hacker1.md b/processes/third_party_vuln_submit_form_hacker1.md deleted file mode 100644 index 31bcd8e78..000000000 --- a/processes/third_party_vuln_submit_form_hacker1.md +++ /dev/null @@ -1,54 +0,0 @@ -> NOTE! Thanks for submitting a report! Please replace *all* the [square] sections below with the pertinent details. Remember, the more detail you provide, the easier it is for us to triage and respond quickly, so be sure to take your time filling out the report! - -I would like to report [VULNERABILITY] in [MODULE] -It allows [DESCRIBE THE IMPACT OF THE VULNERABILITY - E.G READ ARBITRARY FILES, READ DATA FROM DATABASE ETC] - -# Module - -**module name:** [MODULE NAME] -**version:** [MODULE VERSION] -**npm page:** `https://www.npmjs.com/package/[MODULE NAME]` - -## Module Description - -> Copy description from npm page - -## Module Stats - -> Replace stats below with numbers from npm’s module page: - -[X] weekly downloads - -# Vulnerability - -## Vulnerability Description - -> Description about how the vulnerability was found and how it can be exploited, how it harms package users (data modification/lost, system access, other. - -## Steps To Reproduce: - -> Detailed steps to reproduce with all required references/steps/commands. If there is any exploit code or reference to the package source code this is the place where it should be put. - -## Patch - -> If you're able to provide a patch with the fix please post it in this section - -## Supporting Material/References: - -> State all technical information about the stack where the vulnerability was found - -- [OPERATING SYSTEM VERSION] -- [NODEJS VERSION] -- [NPM VERSION] -- [BROWSERS VERSIONS, IF APPLICABLE] -- [OTHER SOFTWARE USED TO EXPLOIT VULNERABILITY AND THEIR VERSIONS, IF APPLICABLE] - -# Wrap up - -> Select Y or N for the following statements: - -- I contacted the maintainer to let them know: [Y/N] -- I opened an issue in the related repository: [Y/N] - -> Hunter's comments and funny memes goes here -