Skip to content

Commit

Permalink
doc: security maintenance processes
Browse files Browse the repository at this point in the history 
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.
  • Loading branch information
@sam-github
sam-github committed Oct 1, 2019
1 parent d9fd2cd commit 0ebbca6
Show file tree
Hide file tree
Showing 3 changed files with 297 additions and 0 deletions.
137 changes: 137 additions & 0 deletions doc/guides/cve_management_process.md
View file
Original file line number Diff line number Diff line change
@@ -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.
61 changes: 61 additions & 0 deletions doc/guides/security_announcement_process.md
View file
Original file line number Diff line number Diff line change
@@ -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.
99 changes: 99 additions & 0 deletions doc/guides/security_release_process.md
View file
Original file line number Diff line number Diff line change
@@ -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.

0 comments on commit 0ebbca6

Please sign in to comment.