diff --git a/README.md b/README.md index 07a6a507..90da2733 100644 --- a/README.md +++ b/README.md @@ -10,9 +10,6 @@ Table of Contents - Vulnerability Management - * [Responsible Disclosure Policy](./processes/responsible_disclosure_template.md) - * [Third-Party Ecosystem Triage Process](./processes/third_party_vuln_process.md) - * [Third-Party HackerOne Submission form](./processes/third_party_vuln_submit_form_hacker1.md) * [Vulnerability Database](./processes/vuln_db.md) * [Recognition for Security Researchers](./processes/recognition.md) - Processes for Security WG Members @@ -20,7 +17,6 @@ Table of Contents * [On-boarding Team Members](./processes/wg_onboarding.md) * [Off-boarding Team Members](./processes/wg_offboarding.md) - [Node.js Bug Bounty Program](#nodejs-bug-bounty-program) -- [Participate in Responsible Security Disclosure](#participate-in-responsible-security-disclosure) - [Charter](#charter) - [Code of Conduct](#code-of-conduct) - [Moderation Policy](#moderation-policy) @@ -38,9 +34,6 @@ Responsibilities include: * Ensure the vulnerability data is updated in an efficient and timely manner. For example, ensuring there are well-documented processes for reporting vulnerabilities in community modules. -* Define and maintain policies and procedures for the coordination of security - concerns within the external Node.js open source ecosystem. -* Offer help to npm package maintainers to fix high-impact security bugs. * Maintain and make available data on disclosed security vulnerabilities in: * the core Node.js project * other projects maintained by the Node.js Foundation technical group @@ -55,20 +48,8 @@ the [Node.js TSC][]. ## Node.js Bug Bounty Program -The Node.js project engages in an official bug bounty program for security researchers and responsible public disclosures. We have established a first draft of accepted criteria and npm modules and projects that are eligible for monetary reward at [Bug Bounty Criteria](./processes/bug_bounty_criteria.md). - The program is managed through the HackerOne platform at [https://hackerone.com/nodejs](https://hackerone.com/nodejs) with further details. -## Participate in Responsible Security Disclosure - -As a module author you can provide your users with security guidelines regarding any exposures and vulnerabilities in your project, based on a responsible disclosure policy [document](https://github.com/nodejs/security-wg/blob/e2c03e62d73635a766156c6ea4f9aefb35c04603/processes/responsible_disclosure_template.md) we've already put in place. - -You can show your users you take security matters seriously and drive higher confidence by following any of the below suggested actions: - -1. Adding a `SECURITY.md` file in your repository that you can copy&paste from [us](https://github.com/nodejs/security-wg/blob/e2c03e62d73635a766156c6ea4f9aefb35c04603/processes/responsible_disclosure_template.md). Just like having a contribution of code of conduct guidelines, a security guideline will help user or bug hunters with the process of reporting a vulnerability or security concern they would like to share. - -2. Adding our Responsible Security Dislosure badge to your project's README which links to the `SECURITY.md` document. - ## Current Project Team Members * [ChALkeR](https://github.com/ChALkeR) - **Сковорода Никита Андреевич** @@ -110,14 +91,6 @@ You can show your users you take security matters seriously and drive higher con * [shigeki](https://github.com/shigeki) - **Shigeki Ohtsu** * [sam-github](https://github.com/sam-github) - **Sam Roberts** -## Ecosystem Vulnerability Triage Team - -Note that membership in the Ecosystem Security WG does not automatically give access to -undisclosed vulnerabilities on HackerOne - -* [*Ecosystem Vulnerabilities*](https://hackerone.com/nodejs-ecosystem): - Managed by the [Ecosystem Triage Team][]. - # Code of Conduct The [Node.js Code of Conduct](https://github.com/nodejs/admin/blob/master/CODE_OF_CONDUCT.md) applies to this WG. @@ -127,4 +100,3 @@ The [Node.js Code of Conduct](https://github.com/nodejs/admin/blob/master/CODE_O The [Node.js Moderation Policy](https://github.com/nodejs/admin/blob/master/Moderation-Policy.md) applies to this WG. [Node.js TSC]: https://github.com/nodejs/TSC -[Ecosystem Triage Team]: processes/third_party_vuln_process.md#members diff --git a/processes/bug_bounty_criteria.md b/processes/bug_bounty_criteria.md deleted file mode 100644 index 500e3e07..00000000 --- a/processes/bug_bounty_criteria.md +++ /dev/null @@ -1,59 +0,0 @@ -# Bug Bounty Criteria - -This document describes the criteria for eligibility of monetary reward for security researchers -who engage with the Node.js Ecosystem -[bug bounty program](https://hackerone.com/nodejs-ecosystem/). - -## Rewards - -As long as budget is available for the Node.js third-party modules program on HackerOne we will -provide the following rewards: - -* Critical bugs: $500 -* High bugs: $250 - -These are also documented publicly on the official program's website on HackerOne: -https://hackerone.com/nodejs-ecosystem/. - -Note that only a specific set of modules are eligible for rewards and they are documented -in the list below as confirmed modules. - - -## Module Characteristics - -1. **Module download count** - x >= 1000 downloads a month which accounts for 7% of npm packages -(courtesy of @ChALkeR here https://github.com/nodejs/security-wg/issues/151#issue-303209104) -2. **Approved Modules** - A list of modules where their maintainers approved to be included in the -bug bounty program - -### Other Module Characteristics (WIP) - -Work-in-progress to assess the following characteristics: - -* **Module dependents count** - we don't have enough experience to gauge what this means -* **Vulnerability type** - Consider instead to have a criteria based on vulnerability severity rather than -type, so to match anything >= 4.0 which means Medium and higher. - -## Modules list - -The following is a list of modules which are eligible in the monetary reward due to their maintainers -explicitly confirming to collaborate with the working group and security researchers to receive and -resolve security reports. - -### Confirmed - -* [lodash](https://github.com/lodash/lodash) (confirmed approval from John-David Dalton) -* [fastify](https://github.com/fastify/fastify) (confirmed approval from Matteo Collina) -* [pino](https://github.com/pinojs/pino) (confirmed approval from Matteo Collina) -* [MQTT.js](https://github.com/mqttjs/MQTT.js) (confirmed approval from Matteo Collina) -* [yarn](https://github.com/yarnpkg/yarn) (confirmed approval from Maël Nison) - -### WIP - -* jQuery -* node-red -* hapi (all packages under the GH org) -* Koajs (all packages under the GH org) -* Webpack -* ESLint -* socket.io diff --git a/processes/responsible_disclosure_template.md b/processes/responsible_disclosure_template.md deleted file mode 100644 index 918967c0..00000000 --- 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 244d2bd3..00000000 --- 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 35eaad83..00000000 --- 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 31bcd8e7..00000000 --- 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 - diff --git a/processes/wg_offboarding.md b/processes/wg_offboarding.md index 6fc7cbc1..8e79c7a9 100644 --- a/processes/wg_offboarding.md +++ b/processes/wg_offboarding.md @@ -18,13 +18,9 @@ At any time until the last time mark any member can chime in and request to reta The following is a check-list of actions to be taken upon departure of users from the Security WG (either voluntarily or due to inactivity as described above): * [ ] Remove user from [Repo README](https://github.com/nodejs/security-wg/blob/master/README.md), [Triage Team](https://github.com/nodejs/security-wg/blob/master/processes/third_party_vuln_process.md) * [ ] Remove membership from [Node.js WG GitHub Team](https://github.com/orgs/nodejs/teams/security-wg) -* [ ] Remove user from [HackerOne platform](https://hackerone.com/nodejs-ecosystem) -* [ ] Revoke any user-specific access tokens from HackerOne platform * [ ] Remove user access from private team channels in [slack](https://nodejs-security-wg.slack.com) The following is a check-list of actions to be taken upon voluntary departure of users from the [Third-Party Triage Team](https://github.com/nodejs/security-wg/blob/master/processes/third_party_vuln_process.md), when the users will remain in the Security WG. * [ ] Remove user from [Triage Team](https://github.com/nodejs/security-wg/blob/master/processes/third_party_vuln_process.md) -* [ ] Remove user from [HackerOne platform](https://hackerone.com/nodejs-ecosystem) -* [ ] Revoke any user-specific access tokens from HackerOne platform * [ ] Remove user access from private team channels in slack that are specific to the Triage Team (nodejs-security-wg.slack.com) diff --git a/processes/wg_onboarding.md b/processes/wg_onboarding.md index 6bd5b99c..8eb90307 100644 --- a/processes/wg_onboarding.md +++ b/processes/wg_onboarding.md @@ -30,8 +30,3 @@ Once acceptance has been acquired by group members, the following should take pl * New member should enable 2FA in GitHub * New member should join the Security WG slack medium and confirm his identity by providing necessary slack user details in the following private discussion: [Slack identity check](https://github.com/orgs/nodejs/teams/security-wg/discussions/3) -## Setting-up for new Triage Team members -Please follow: -* New member should open a PR with his username added to [security-wg/third_party_vuln_process.md at master · nodejs/security-wg · GitHub](https://github.com/nodejs/security-wg/blob/master/processes/third_party_vuln_process.md#the-triage-team), where the username list is ordered alphabetically. -* New members should familiarize themselves with the 3rd party vulnerability triage process at: [security-wg/third_party_vuln_process.md at master · nodejs/security-wg · GitHub](https://github.com/nodejs/security-wg/blob/master/processes/third_party_vuln_process.md) -* New members should schedule an on-boarding demo session with their mentor to review the HackerOne platform where the new member receives a walk-through of our triage process.