Skip to content

Commit 0b46bca

Browse files
sam-githubBridgeAR
sam-github
authored and
BridgeAR
committed
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: #29685 Reviewed-By: Michael Dawson <[email protected]>
1 parent f39259c commit 0b46bca

File tree

3 files changed

+297
-0
lines changed

3 files changed

+297
-0
lines changed

‎doc/guides/cve_management_process.md

Lines changed: 137 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,137 @@
1+
# Node.js CVE management process
2+
3+
The Node.js project acts as a [Common Vulnerabilities and Exposures (CVE)
4+
Numbering Authority (CNA)](https://cve.mitre.org/cve/cna.html).
5+
The current scope is for all actively developed versions of software
6+
developed under the Node.js project (ie. https://github.com/nodejs).
7+
This means that the Node.js team reviews CVE requests and if appropriate
8+
assigns CVE numbers to vulnerabilities. The scope currently **does not**
9+
include third party modules.
10+
11+
More detailed information about the CNA program is available in
12+
[CNA_Rules_v1.1](https://cve.mitre.org/cve/cna/CNA_Rules_v1.1.pdf).
13+
14+
## Contacts
15+
16+
As part of the CNA program the Node.js team must provide a number
17+
of contact points. Email aliases have been setup for these as follows:
18+
19+
* **Public contact points**. Email address to which people will be directed
20+
by Mitre when they are asked for a way to contact the Node.js team about
21+
CVE-related issues. **[email protected]**
22+
23+
* **Private contact points**. Administrative contacts that Mitre can reach out
24+
to directly in case there are issues that require immediate attention.
25+
**[email protected]**
26+
27+
* **Email addresses to add to the CNA email discussion list**. This address has
28+
been added to a closed mailing list that is used for announcements,
29+
sharing documents, or discussion relevant to the CNA community.
30+
The list rarely has more than ten messages a week.
31+
**[email protected]**
32+
33+
## CNA management processes
34+
35+
### CVE Block management
36+
37+
The CNA program allows the Node.js team to request a block of CVEs in
38+
advance. These CVEs are managed in a repository within the Node.js
39+
private organization called
40+
[cve-management](https://github.com/nodejs-private/cve-management).
41+
For each year there will be a markdown file titled "cve-management-XXXX"
42+
where where XXXX is the year (for example 'cve-management-2017.md').
43+
44+
This file will have the following sections:
45+
46+
* Available
47+
* Pending
48+
* Announced
49+
50+
When a new block of CVEs is received from Mitre they will be listed under
51+
the `Available` section.
52+
53+
These CVEs will be moved from the Available to Pending and Announced
54+
as outlined in the section titled `CVE Management process`.
55+
56+
In addition, when moving a CVE from Available such that there are less
57+
than two remaining CVEs a new block must be requested as follows:
58+
59+
* Use the Mitre request form https://cveform.mitre.org/ with the
60+
option `Request a Block of IDs` to request a new block.
61+
* The new block will be sent to the requester through email.
62+
* Once the new block has been received, the requester will add them
63+
to the Available list.
64+
65+
All changes to the files for managing CVEs in a given year will
66+
be done through Pull Requests so that we have a record of how
67+
the CVEs have been assigned.
68+
69+
CVEs are only valid for a specific year. At the beginning of each
70+
year the old CVEs should be removed from the list. A new block
71+
of CVEs should then be requested using the steps listed above.
72+
73+
### External CVE request process
74+
75+
When a request for a CVE is received via the [email protected]
76+
email alias the following process will be followed (likely updated
77+
after we get HackerOne up and running).
78+
79+
* Respond to the requester indicating that we have the request
80+
and will review soon.
81+
* Open an issue in the security repo for the request.
82+
* Review the request.
83+
* If a CVE is appropriate then assign the
84+
CVE as outline in the section titled
85+
[CVE Management process for Node.js vulnerabilities](cve-management-process-for-nodejs-vulnerabilities)
86+
and return the CVE number to the requester (along with the request
87+
to keep it confidential until the vulnerability is announced)
88+
* If a CVE is not appropriate then respond to the requester
89+
with the details as to why.
90+
91+
### Quarterly reporting
92+
93+
* There is a requirement for quarterly reports to Mitre on CVE
94+
activity. Not sure of the specific requirements yet. Will
95+
add details on process once we've done the first one.
96+
97+
## CVE Management process for Node.js vulnerabilities
98+
99+
When the Node.js team is going announce a new vulnerability the
100+
following steps are used to assign, announce and report a CVE.
101+
102+
* Select the next CVE in the block available from the CNA process as
103+
outlined in the section above.
104+
* Move the CVE from the unassigned block, to the Pending section along
105+
with a link to the issue in the security repo that is being used
106+
to discuss the vulnerability.
107+
* As part of the
108+
[security announcement process](https://github.com/nodejs/security-wg/blob/master/processes/security_annoucement_process.md),
109+
in the security issue being used to discuss the
110+
vulnerability, associate the CVE to that vulnerability. This is most
111+
commonly done by including it in the draft for the announcement that
112+
will go out once the associated security releases are available.
113+
* Once the security announcement goes out:
114+
* Use the [Mitre form](https://cveform.mitre.org/) to report the
115+
CVE details to Mitre using the `Notify CVE about a publication`. The
116+
link to the advisory will be the for the blog announcing that security
117+
releases are available. The description should be a subset of the
118+
details in that blog.
119+
120+
Ensure that the contact address entered in the form is
121+
`[email protected]`. Anything else may require slow, manual
122+
verification of the identity of the CVE submitter.
123+
124+
For each CVE listed, the additional data must include the following fields
125+
updated with appropriate data for the CVE
126+
```text
127+
[CVEID]: CVE-XXXX-XXXX
128+
[PRODUCT]: Node.js
129+
[VERSION]: 8.x+, 9.x+, 10.x+
130+
[PROBLEMTYPE]: Denial of Service
131+
[REFERENCES]: Link to the blog for the final announce
132+
[DESCRIPTION]: Description from final announce
133+
[ASSIGNINGCNA]: Node.js Foundation
134+
```
135+
* Move the CVE from the Pending section to the Announced section along
136+
with a link to the Node.js blog post announcing that releases
137+
are available.

‎doc/guides/security_announcement_process.md

Lines changed: 61 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,61 @@
1+
The Node.js community follows a process to create/review and
2+
then publish vulnerability announcements. It is most often a 2 step
3+
process where we:
4+
5+
* announce that releases will be made to fix an embargoed vulnerability
6+
* announce that the releases with the fixes are available
7+
8+
The process is as follows:
9+
10+
* Security vulnerabilties are initially discussed/reviewed in the private
11+
security repository.
12+
13+
* Once we are ready to release an anouncement of an upcoming fix for the
14+
the vulnerability, on the issue for the security vulnerability in private
15+
security repo, propose candidate text based on past announcements.
16+
17+
* Once reviewed, agree on timing for the releases with the fix and line up
18+
releasers to make sure they are available to do the release on that date.
19+
20+
* Post to https://groups.google.com/forum/#!forum/nodejs-sec.
21+
**Note** that you will need to have been given access by one of the
22+
existing managers (Ben Noordhuis, Rod Vagg, Trevor Norris, Michael Dawson).
23+
You will have to manually edit to add formatting and links properly.
24+
25+
* Mirror post in vulnerabilities section of Nodejs.org blog section
26+
(https://github.com/nodejs/nodejs.org/tree/master/locale/en/blog/vulnerability)
27+
Submit PR and leave 1 hour for review. After one hour even if no reviews,
28+
land anyway so that we don't have too big a gap between post to nodejs-sec
29+
and blog. Text was already reviewed in security repo so is unlikely to
30+
attract much additional comment. **The PR should also update the banner
31+
on the Node.js website to indicate security releases are coming with the
32+
banner linked to the blog**
33+
34+
* In original PR for the security repository for the issue, post candidate
35+
text for updates that will go out with releases that will indicates
36+
releases are available and include full vulnerability details.
37+
38+
* Once releases are made, post response to original message in
39+
https://groups.google.com/forum/#!forum/nodejs-sec indicating
40+
releases are available and with the full vulnerability details.
41+
42+
* Update the blog post in
43+
https://github.com/nodejs/nodejs.org/tree/master/locale/en/blog/vulnerability
44+
with the information that releases are available and the full
45+
vulnerability details. Keep the original blog content at the
46+
bottom of the blog. This is an example:
47+
https://github.com/nodejs/nodejs.org/blob/master/locale/en/blog/vulnerability/june-2016-security-releases.md.
48+
Make sure to update the date in the slug so that it will move to
49+
the top of the blog list. **As part of the PR, update the
50+
banner on Node.js org to indicate the security release are
51+
available.**
52+
53+
*Note*: If the release blog obviously points to the people having caused the
54+
issue (for example when explicitly mentioning reverting a commit), adding
55+
those people as a CC on the PR for the blog post to give them a heads up
56+
might be appropriate.
57+
58+
* Tweet out a link to the nodejs-sec announcement.
59+
60+
* Email foundation contact to tweet out nodejs-sec announcement from
61+
foundation twitter account.

‎doc/guides/security_release_process.md

Lines changed: 99 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,99 @@
1+
# Security Release Process
2+
3+
The security release process covers the steps required to plan/implement
4+
a security release.
5+
6+
## Planning
7+
8+
* [ ] Open an issue in the private security repo titled `Next Security Release`
9+
and add the planning checklist to the description.
10+
11+
* [ ] Get agreement on the list of vulnerabilities to be addressed.
12+
13+
* [ ] Get agreement on the planned date for the releases.
14+
15+
* [ ] Once agreement on the list and date has been agreed, validate that all
16+
vulnerabilities have been assigned a CVE following the
17+
[cve_management_process](https://github.com/nodejs/security-wg/blob/master/processes/cve_management_process.md).
18+
19+
* [ ] Co-ordinate with the Release team members to line up one or more releasers
20+
to do the releases on the agreed date.
21+
22+
* [ ] Prep for the pre-security announcement and final security annoucement by
23+
getting agreement on drafts following the
24+
[security_announcement_process](https://github.com/nodejs/security-wg/blob/master/processes/security_annoucement_process.md).
25+
26+
## Announcement (one week in advance of the planned release)
27+
28+
* [ ] Ensure the pre-announce is sent out as outlined in the
29+
[security_announcement_process](https://github.com/nodejs/security-wg/blob/master/processes/security_annoucement_process.md).
30+
31+
* [ ] Open an issue in the build working repository with a notification of the
32+
date for the security release. Use this issue to co-ordinate with the build
33+
team to ensure there will be coverage/availability of build team resources the
34+
day of the release. Those who volunteer from the build WG should be available
35+
in node-build during the release in case they are needed by the individual
36+
doing the release.
37+
38+
* [ ] Send an email to the docker official image
39+
[maintainers](https://github.com/docker-library/official-images/blob/master/MAINTAINERS)
40+
with an FYI that security releases will be going out on the agreed date.
41+
42+
* [ ] Open an issue in the [docker-node](https://github.com/nodejs/docker-node)
43+
repo and get one or more volunteers to be available to review the PR to update
44+
Node.js versions in the docker-node repo immediately after the release.
45+
46+
* [ ] Call on the sec release volunteer(s) to start integrating the PRs, running
47+
the CI jobs, and generally prepping the release.
48+
49+
## Release day
50+
51+
* [ ] Co-ordinate with the Release team members and keep up to date on progress.
52+
Get an guesstimate of when releases may be ready and send an FYI to the docker
53+
offical image
54+
[maintainers](https://github.com/docker-library/official-images/blob/master/MAINTAINERS).
55+
56+
* [ ] When the releases are promoted, ensure the final announce goes out as per
57+
the
58+
[security_announcement_process](https://github.com/nodejs/security-wg/blob/master/processes/security_annoucement_process.md).
59+
60+
* [ ] Create a PR to update the Node.js version in the official docker images.
61+
* Checkout the docker-node repo.
62+
* Run the update.sh using the `-s` option so that ONLY the Node.js
63+
versions are updated. At the request from docker (and because
64+
it is good practice) we limit the changes to those necessary in
65+
security updates.
66+
* Open a PR and get volunteer lined up earlier to approve.
67+
* Merge the PR with the merge button.
68+
* Checkout the [official-images](https://github.com/docker-library/official-images)
69+
repository .
70+
* In the docker-node repository run the
71+
[generate-stackbrew-library.sh]( https://github.com/nodejs/docker-node/blob/master/generate-stackbrew-library.sh)
72+
script and replace official-images/library/node with the output generated.
73+
```shell
74+
$ ./generate-stackbrew-library.sh > .../official-images/library/node
75+
```
76+
* Open a PR with the changes to official-images/library/node making sure to
77+
@mention the official images.
78+
[maintainers](https://github.com/docker-library/official-images/blob/master/MAINTAINERS).
79+
In addition, make sure to prefix the PR title with `[security]`.
80+
* Send an email to the
81+
[maintainers](https://github.com/docker-library/official-images/blob/master/MAINTAINERS)
82+
indicating that the PR is open.
83+
84+
* [ ] Ensure that the announced CVEs are reported to Mitre as per the
85+
[cve_management_process](https://github.com/nodejs/security-wg/blob/master/processes/cve_management_process.md).
86+
87+
* [ ] Ensure that the announced CVEs are updated in the cve-management
88+
repository as per the the
89+
[cve_management_process](https://github.com/nodejs/security-wg/blob/master/processes/cve_management_process.md)
90+
so that they are listed under Announced.
91+
92+
* [ ] PR machine-readable JSON descriptions of the vulnerabilities to the
93+
[core](https://github.com/nodejs/security-wg/tree/master/vuln/core)
94+
vulnerability DB.
95+
96+
* [ ] Make sure the PRs for the vulnerabilities are closed.
97+
98+
* [ ] Ensure the issue in the private security repo for the release is closed
99+
out.

0 commit comments

Comments
 (0)