diff --git a/README.md b/README.md index d63d42143..6f79170f0 100644 --- a/README.md +++ b/README.md @@ -5,14 +5,11 @@ [![Security Responsible Disclosure](https://img.shields.io/badge/Security-Responsible%20Disclosure-yellow.svg)](https://github.com/nodejs/security-wg/blob/master/processes/responsible_disclosure_template.md ) -# Security Working Group +# Ecosystem Security Working Group Table of Contents - Vulnerability Management - * [Security Announcement Process](./processes/security_annoucement_process.md) - * [Security Release Process](./processes/security_release_process.md) - * [Node.js CVE management process](./processes/cve_management_process.md) * [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) @@ -22,7 +19,6 @@ Table of Contents * [Security Team Membership Policy](./processes/security_team_membership_policy.md) * [On-boarding Team Members](./processes/security_team_onboarding.md) * [Off-boarding Team Members](./processes/security_team_offboarding.md) -- [Private Node.js core security group](#private-nodejs-core-security-group) - [Node.js Bug Bounty Program](#nodejs-bug-bounty-program) - [Participate in Responsible Security Disclosure](#participate-in-responsible-security-disclosure) - [Charter](#charter) @@ -34,20 +30,14 @@ Table of Contents ## [Charter](https://github.com/nodejs/TSC/blob/master/WORKING_GROUPS.md#security) -The Security Working Group manages all aspects and processes linked to Node.js security. +The Ecosystem Security Working Group works to improve the security of the Node.js Ecosystem. Responsibilities include: -* Define and maintain security policies and procedures for: - * the core Node.js project - * other projects maintained by the Node.js Technical Steering Committee (TSC). * Work with the Node Security Platform to bring community vulnerability data into the foundation as a shared asset. * 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. -* Review and recommend processes for handling of security reports (but not the - actual administration of security reports, which are reviewed by a group of people - directly delegated to by the TSC). * 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. @@ -56,20 +46,12 @@ Responsibilities include: * other projects maintained by the Node.js Foundation technical group * the external Node.js open source ecosystem * Promote the improvement of security practices within the Node.js ecosystem. -* Recommend security improvements for the core Node.js project. * Facilitate and promote the expansion of a healthy security service and product provider ecosystem. -## Private Node.js core security group - -The Node.js Security Working Group is _not_ responsible for managing incoming -security reports to the security@nodejs.org address, nor is it privy to or -responsible for preparing embargoed security patches and releases. - -The [Node.js TSC][] maintains primary responsibility for the management of private -security activities for Node.js core but relies on the Node.js Security Working -Group to recommend and help maintain policies and procedures for that -management. +This Working Group is _not_ responsible for managing or responding to +security reports against Node.js itself. That responsibility remains with +the [Node.js TSC][]. ## Node.js Bug Bounty Program @@ -125,21 +107,14 @@ You can show your users you take security matters seriously and drive higher con * [roccomuso](https://github.com/roccomuso) - **Rocco Musolino** * [shigeki](https://github.com/shigeki) - **Shigeki Ohtsu** -## Vulnerability Triage Teams +## Ecosystem Vulnerability Triage Team -There are two Triage Teams associated with Node.js. They have different scopes, -different HackerOne programs, and they don't share members (though an -individual may be a member of both teams). - -Note that membership in the Security WG does not automatically give access to -undisclosed vulnerabilities in any of the Node.js programs on HackerOne +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][]. -* [*Node.js Vulnerabilities*](https://hackerone.com/nodejs): Managed by the - [Node.js 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. @@ -150,4 +125,3 @@ The [Node.js Moderation Policy](https://github.com/nodejs/admin/blob/master/Mode [Node.js TSC]: https://github.com/nodejs/TSC [Ecosystem Triage Team]: processes/third_party_vuln_process.md#members -[Node.js Triage Team]: processes/security_team_members.md#team-that-triages-security-reports-against-node-core diff --git a/processes/cve_management_process.md b/processes/cve_management_process.md deleted file mode 100644 index 376255a05..000000000 --- a/processes/cve_management_process.md +++ /dev/null @@ -1,137 +0,0 @@ -# Node.js CVE management process - -The Node.js project acts as a [Common Vulnerabilities and Exposures (CVE) -Numbering Authority (CNA)](https://cve.mitre.org/cve/cna.html). -The current scope is for all actively developed versions of software -developed under the Node.js project (ie. https://github.com/nodejs). -This means that the Node.js team reviews CVE requests and if appropriate -assigns CVE numbers to vulnerabilities. The scope currently **does not** -include third party modules. - -More detailed information about the CNA program is available in -[CNA_Rules_v1.1](https://cve.mitre.org/cve/cna/CNA_Rules_v1.1.pdf). - -# Contacts - -As part of the CNA program the Node.js team must provide a number -of contact points. Email aliases have been setup for these as follows: - -* **Public contact points**. Email address to which people will be directed - by Mitre when they are asked for a way to contact the Node.js team about - CVE-related issues. **cve-request@iojs.org** - -* **Private contact points**. Administrative contacts that Mitre can reach out - to directly in case there are issues that require immediate attention. - **cve-mitre-contact@iojs.org** - -* **Email addresses to add to the CNA email discussion list**. This address has - been added to a closed mailing list that is used for announcements, - sharing documents, or discussion relevant to the CNA community. - The list rarely has more than ten messages a week. - **cna-discussion-list@iojs.org** - -# CNA management processes - -## CVE Block management - -The CNA program allows the Node.js team to request a block of CVEs in -advance. These CVEs are managed in a repository within the Node.js -private organization called -[cve-management](https://github.com/nodejs-private/cve-management). -For each year there will be a markdown file titled "cve-management-XXXX" -where where XXXX is the year (for example 'cve-management-2017.md'). - -This file will have the following sections: - -* Available -* Pending -* Announced - -When a new block of CVEs is received from Mitre they will be listed under -the `Available` section. - -These CVEs will be moved from the Available to Pending and Announced -as outlined in the section titled `CVE Management process`. - -In addition, when moving a CVE from Available such that there are less -than two remaining CVEs a new block must be requested as follows: - -* Use the Mitre request form https://cveform.mitre.org/ with the - option `Request a Block of IDs` to request a new block. -* The new block will be sent to the requester through email. -* Once the new block has been received, the requester will add them - to the Available list. - -All changes to the files for managing CVEs in a given year will -be done through Pull Requests so that we have a record of how -the CVEs have been assigned. - -CVEs are only valid for a specific year. At the beginning of each -year the old CVEs should be removed from the list. A new block -of CVEs should then be requested using the steps listed above. - -## External CVE request process - -When a request for a CVE is received via the cve-request@iojs.org -email alias the following process will be followed (likely updated -after we get HackerOne up and running). - -* Respond to the requester indicating that we have the request - and will review soon. -* Open an issue in the security repo for the request. -* Review the request. - * If a CVE is appropriate then assign the - CVE as outline in the section titled - [CVE Management process for Node.js vulnerabilities](cve-management-process-for-nodejs-vulnerabilities) - and return the CVE number to the requester (along with the request - to keep it confidential until the vulnerability is announced) - * If a CVE is not appropriate then respond to the requester - with the details as to why. - -## Quarterly reporting - -* There is a requirement for quarterly reports to Mitre on CVE - activity. Not sure of the specific requirements yet. Will - add details on process once we've done the first one. - -# CVE Management process for Node.js vulnerabilities - -When the Node.js team is going announce a new vulnerability the -following steps are used to assign, announce and report a CVE. - -* Select the next CVE in the block available from the CNA process as - outlined in the section above. -* Move the CVE from the unassigned block, to the Pending section along - with a link to the issue in the security repo that is being used - to discuss the vulnerability. -* As part of the - [security announcement process](https://github.com/nodejs/security-wg/blob/master/processes/security_annoucement_process.md), - in the security issue being used to discuss the - vulnerability, associate the CVE to that vulnerability. This is most - commonly done by including it in the draft for the announcement that - will go out once the associated security releases are available. -* Once the security announcement goes out: - * Use the [Mitre form](https://cveform.mitre.org/) to report the - CVE details to Mitre using the `Notify CVE about a publication`. The - link to the advisory will be the for the blog announcing that security - releases are available. The description should be a subset of the - details in that blog. - - Ensure that the contact address entered in the form is - `cve-mitre-contact@iojs.org`. Anything else may require slow, manual - verification of the identity of the CVE submitter. - - For each CVE listed, the additional data must include the following fields - updated with appropriate data for the CVE -``` - [CVEID]: CVE-XXXX-XXXX - [PRODUCT]: Node.js - [VERSION]: 8.x+, 9.x+, 10.x+ - [PROBLEMTYPE]: Denial of Service - [REFERENCES]: Link to the blog for the final announce - [DESCRIPTION]: Description from final announce - [ASSIGNINGCNA]: Node.js Foundation -``` -* Move the CVE from the Pending section to the Announced section along - with a link to the Node.js blog post announcing that releases - are available. diff --git a/processes/security_annoucement_process.md b/processes/security_annoucement_process.md deleted file mode 100644 index 06b124159..000000000 --- a/processes/security_annoucement_process.md +++ /dev/null @@ -1,63 +0,0 @@ -The Node.js community follows a process to create/review and -then publish vulnerability announcements. It is most often a 2 step -process where we: - -* announce that releases will be made to fix an embargoed vulnerability -* announce that the releases with the fixes are available - -The process is as follows: - -* Security vulnerabilties are initially discussed/reviewed in the private - security repository. - -* Once we are ready to release an anouncement of an upcoming fix for the - the vulnerability, on the issue for the security vulnerability in private - security repo, propose candidate text based on past announcements. - -* Once reviewed, agree on timing for the releases with the fix and line up - releasers to make sure they are available to do the release on that date. - -* Post to https://groups.google.com/forum/#!forum/nodejs-sec. - **Note** that you will need to have been given access by one of the - existing managers (Ben Noordhuis, Rod Vagg, Trevor Norris, Michael Dawson). - You will have to manually edit to add formatting and links properly. - -* Mirror post in vulnerabilities section of Nodejs.org blog section - (https://github.com/nodejs/nodejs.org/tree/master/locale/en/blog/vulnerability) - Submit PR and leave 1 hour for review. After one hour even if no reviews, - land anyway so that we don't have too big a gap between post to nodejs-sec - and blog. Text was already reviewed in security repo so is unlikely to - attract much additional comment. **The PR should also update the banner - on the Node.js website to indicate security releases are coming with the - banner linked to the blog** - -* In original PR for the security repository for the issue, post candidate - text for updates that will go out with releases that will indicates - releases are available and include full vulnerability details. - -* Once releases are made, post response to original message in - https://groups.google.com/forum/#!forum/nodejs-sec indicating - releases are available and with the full vulnerability details. - -* Update the blog post in - https://github.com/nodejs/nodejs.org/tree/master/locale/en/blog/vulnerability - with the information that releases are available and the full - vulnerability details. Keep the original blog content at the - bottom of the blog. This is an example: - ``` - https://github.com/nodejs/nodejs.org/blob/master/locale/en/blog/vulnerability/june-2016-security-releases.md. - ``` - Make sure to update the date in the slug so that it will move to - the top of the blog list. **As part of the PR, update the - banner on Node.js org to indicate the security release are - available.** - - *Note*: If the release blog obviously points to the people having caused the - issue (for example when explicitly mentioning reverting a commit), adding - those people as a CC on the PR for the blog post to give them a heads up - might be appropriate. - -* Tweet out a link to the nodejs-sec announcement. - -* Email foundation contact to tweet out nodejs-sec announcement from - foundation twitter account. diff --git a/processes/security_release_process.md b/processes/security_release_process.md deleted file mode 100644 index ba5063209..000000000 --- a/processes/security_release_process.md +++ /dev/null @@ -1,100 +0,0 @@ -# Security Release Process - -The security release process covers the steps required to plan/implement -a security release. - - -## Planning - -- [ ] Open an issue in the private security repo titled `Next Security Release` - and add the planning checklist to the description. - -- [ ] Get agreement on the list of vulnerabilities to be addressed. - -- [ ] Get agreement on the planned date for the releases. - -- [ ] Once agreement on the list and date has been agreed, validate that all - vulnerabilities have been assigned a CVE following the - [cve_management_process](https://github.com/nodejs/security-wg/blob/master/processes/cve_management_process.md). - -- [ ] Co-ordinate with the Release team members to line up one or more releasers - to do the releases on the agreed date. - -- [ ] Prep for the pre-security announcement and final security annoucement by - getting agreement on drafts following the - [security_announcement_process](https://github.com/nodejs/security-wg/blob/master/processes/security_annoucement_process.md). - -## Announcement (one week in advance of the planned release) - -- [ ] Ensure the pre-announce is sent out as outlined in the - [security_announcement_process](https://github.com/nodejs/security-wg/blob/master/processes/security_annoucement_process.md). - -- [ ] Open an issue in the build working repository with a notification of the - date for the security release. Use this issue to co-ordinate with the build - team to ensure there will be coverage/availability of build team resources the - day of the release. Those who volunteer from the build WG should be available - in node-build during the release in case they are needed by the individual - doing the release. - -- [ ] Send an email to the docker official image - [maintainers](https://github.com/docker-library/official-images/blob/master/MAINTAINERS) - with an FYI that security releases will be going out on the agreed date. - -- [ ] Open an issue in the [docker-node](https://github.com/nodejs/docker-node) - repo and get one or more volunteers to be available to review the PR to update - Node.js versions in the docker-node repo immediately after the release. - -- [ ] Call on the sec release volunteer(s) to start integrating the PRs, running - the CI jobs, and generally prepping the release. - -## Release day - -- [ ] Co-ordinate with the Release team members and keep up to date on progress. - Get an guesstimate of when releases may be ready and send an FYI to the docker - offical image - [maintainers](https://github.com/docker-library/official-images/blob/master/MAINTAINERS). - -- [ ] When the releases are promoted, ensure the final announce goes out as per - the - [security_announcement_process](https://github.com/nodejs/security-wg/blob/master/processes/security_annoucement_process.md). - -- [ ] Create a PR to update the Node.js version in the official docker images. - * Checkout the docker-node repo. - * Run the update.sh using the `-s` option so that ONLY the Node.js - versions are updated. At the request from docker (and because - it is good practice) we limit the changes to those necessary in - security updates. - * Open a PR and get volunteer lined up earlier to approve. - * Merge the PR with the merge button. - * Checkout the [official-images](https://github.com/docker-library/official-images) - repository . - * In the docker-node repository run the - [generate-stackbrew-library.sh]( https://github.com/nodejs/docker-node/blob/master/generate-stackbrew-library.sh) - script and replace official-images/library/node with the output generated. - - $ ./generate-stackbrew-library.sh > .../official-images/library/node - - * Open a PR with the changes to official-images/library/node making sure to - @mention the official images. - [maintainers](https://github.com/docker-library/official-images/blob/master/MAINTAINERS). - In addition, make sure to prefix the PR title with `[security]`. - * Send an email to the - [maintainers](https://github.com/docker-library/official-images/blob/master/MAINTAINERS) - indicating that the PR is open. - -- [ ] Ensure that the announced CVEs are reported to Mitre as per the - [cve_management_process](https://github.com/nodejs/security-wg/blob/master/processes/cve_management_process.md). - -- [ ] Ensure that the announced CVEs are updated in the cve-management - repository as per the the - [cve_management_process](https://github.com/nodejs/security-wg/blob/master/processes/cve_management_process.md) - so that they are listed under Announced. - -- [ ] PR machine-readable JSON descriptions of the vulnerabilities to the - [core](https://github.com/nodejs/security-wg/tree/master/vuln/core) - vulnerability DB. - -- [ ] Make sure the PRs for the vulnerabilities are closed. - -- [ ] Ensure the issue in the private security repo for the release is closed - out. diff --git a/processes/security_team_members.md b/processes/security_team_members.md deleted file mode 100644 index 288e8063e..000000000 --- a/processes/security_team_members.md +++ /dev/null @@ -1,94 +0,0 @@ -# Node.js Security Team - -Node.js security team members are expected to keep all information that they have -privileged access to by being on the team completely private to the team. This -includes agreeing to not notify anyone outside the team of issues that have not -yet been disclosed publicly, including the existence of issues, expectations of -upcoming releases, and patching of any issues other than in the process of their -work as a member of the security team. - -## Node.js Security Team Membership Policy - -The Node.js Security Team has access to security-sensitive issues and patches -that aren't appropriate for public availability. - -The policy for inclusion is as follows: - -1. All members of @nodejs/TSC have access to private security reports and - private patches. -2. Members of the [release team](https://github.com/nodejs/node#release-team) - have access to private security patches in order to produce releases. -3. On a case-by-case basis, individuals outside the Technical Steering - Committee are invited by the TSC to have access to private security reports - or private patches so that their expertise can be applied to an issue or - patch. This access may be temporary or permanent, as decided by the TSC. - -Membership on the security teams can be requested via an issue in the TSC repo. - -## Team responsible for Triaging security reports - -Initial triage is done by HackerOne staff. Once enough information is gathered -to confirm there is a reproducible issue, triage is assigned to this group. - -- @bnoordhuis - **Ben Noordhuis** -- @cjihrig - **Colin Ihrig** -- @indutny - **Fedor Indutny** -- @jasnell - **James M Snell** -- @mcollina - **Matteo Colina** -- @MylesBorins - **Myles Borins** -- @rvagg - **Rod Vagg** -- @vdeturckheim - **Vladimir de Turckheim** - -## Team with access to private security reports against Node.js - -The [TSC](https://github.com/nodejs/node#tsc-technical-steering-committee) -have access. - -These non-TSC and TSC Emeriti also have access: -* [bnoordhuis](https://github.com/bnoordhuis) - **Ben Noordhuis** -* [indutny](https://github.com/indutny) - **Fedor Indutny** -* [rvagg](https://github.com/rvagg) - **Rod Vagg** -* [vdeturckheim](https://github.com/vdeturckheim) - **Vladimir de Turckheim** - -List is from the [member page](https://hackerone.com/nodejs/team_members) for -the Node.js program on HackerOne. - -## Team with access to private security patches to Node.js - - - -- [@addaleax](https://github.com/addaleax) - Anna Henningsen -- [@apapirovski](https://github.com/apapirovski) - Anatoli Papirovski -- [@BethGriggs](https://github.com/BethGriggs) - Bethany Nicolle Griggs -- [@bnoordhuis](https://github.com/bnoordhuis) - Ben Noordhuis -- [@BridgeAR](https://github.com/BridgeAR) - Ruben Bridgewater -- [@ChALkeR](https://github.com/ChALkeR) - Сковорода Никита Андреевич -- [@cjihrig](https://github.com/cjihrig) - Colin Ihrig -- [@codebytere](https://github.com/codebytere) - Shelley Vohr -- [@danbev](https://github.com/danbev) - Daniel Bevenius -- [@dougwilson](https://github.com/dougwilson) - Douglas Wilson -- [@evanlucas](https://github.com/evanlucas) - Evan Lucas -- [@evilpacket](https://github.com/evilpacket) - Adam Baldwin -- [@fhinkel](https://github.com/fhinkel) - F. Hinkelmann -- [@Fishrock123](https://github.com/Fishrock123) - Jeremiah Senkpiel -- [@gabrielschulhof](https://github.com/gabrielschulhof) - Gabriel Schulhof -- [@gibfahn](https://github.com/gibfahn) - Gibson Fahnestock -- [@gireeshpunathil](https://github.com/gireeshpunathil) - Gireesh Punathil -- [@indutny](https://github.com/indutny) - Fedor Indutny -- [@jasnell](https://github.com/jasnell) - James M Snell -- [@jbergstroem](https://github.com/jbergstroem) - Johan Bergström -- [@joaocgreis](https://github.com/joaocgreis) - João Reis -- [@joyeecheung](https://github.com/joyeecheung) - Joyee Cheung -- [@mcollina](https://github.com/mcollina) - Matteo Collina -- [@mhdawson](https://github.com/mhdawson) - Michael Dawson -- [@MylesBorins](https://github.com/MylesBorins) - Myles Borins -- [@rvagg](https://github.com/rvagg) - Rod Vagg -- [@saghul](https://github.com/saghul) - Saúl Ibarra Corretgé -- [@sam-github](https://github.com/sam-github) - Sam Roberts -- [@shigeki](https://github.com/shigeki) - Shigeki Ohtsu -- [@targos](https://github.com/targos) - Michaël Zasso -- [@thefourtheye](https://github.com/thefourtheye) - Sakthipriyan Vairamani -- [@Trott](https://github.com/Trott) - Rich Trott -- [@vdeturckheim](https://github.com/vdeturckheim) - Vladimir de Turckheim - -