From 0ebbca6433aa6e3d5fcdce8f40c3c66d810e9e9c Mon Sep 17 00:00:00 2001 From: Sam Roberts Date: Mon, 23 Sep 2019 16:28:23 -0700 Subject: [PATCH] doc: security maintenance processes The TSC has responsibility for Node.js security, so avoid fragmentation of the Node.js maintenance process documentation by adding it to the other guides. --- doc/guides/cve_management_process.md | 137 ++++++++++++++++++++ doc/guides/security_announcement_process.md | 61 +++++++++ doc/guides/security_release_process.md | 99 ++++++++++++++ 3 files changed, 297 insertions(+) create mode 100644 doc/guides/cve_management_process.md create mode 100644 doc/guides/security_announcement_process.md create mode 100644 doc/guides/security_release_process.md diff --git a/doc/guides/cve_management_process.md b/doc/guides/cve_management_process.md new file mode 100644 index 00000000000000..1b1c4e1ec866dc --- /dev/null +++ b/doc/guides/cve_management_process.md @@ -0,0 +1,137 @@ +# 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 +```text + [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/doc/guides/security_announcement_process.md b/doc/guides/security_announcement_process.md new file mode 100644 index 00000000000000..86b3a81bf62889 --- /dev/null +++ b/doc/guides/security_announcement_process.md @@ -0,0 +1,61 @@ +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/doc/guides/security_release_process.md b/doc/guides/security_release_process.md new file mode 100644 index 00000000000000..a3db841f51b03c --- /dev/null +++ b/doc/guides/security_release_process.md @@ -0,0 +1,99 @@ +# 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. +```shell +$ ./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.