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.

PR-URL: https://github.com/nodejs/node/pull/29685
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>

3 files changed, 297 insertions, 0 deletions

diff --git a/doc/guides/cve_management_process.md b/doc/guides/cve_management_process.md
new file mode 100644
index 0000000000..1b1c4e1ec8
--- /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 0000000000..86b3a81bf6
--- /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 0000000000..a3db841f51
--- /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.