-
Notifications
You must be signed in to change notification settings - Fork 122
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
doc: add initial draft of CVE management process
PR-URL: #60 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Sam Roberts <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
- Loading branch information
Showing
1 changed file
with
118 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,118 @@ | ||
# 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. **[email protected]** | ||
|
||
* **Private contact points**. Administrative contacts that Mitre can reach out | ||
to directly in case there are issues that require immediate attention. | ||
**[email protected]** | ||
|
||
* **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. | ||
**[email protected]** | ||
|
||
# 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 an a repository within the Node.js | ||
private organization called | ||
[cve-management](https://github.com/nodejs-private/cve-management). | ||
For each year there will be 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` secion. | ||
|
||
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 CVEs to request a new block`. | ||
* The new block will be sent to the requestor through email. | ||
* Once the new block has been received, the requestor 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. | ||
|
||
## External CVE request process | ||
|
||
When a request for a CVE is received via the [email protected] | ||
email alias the following process will be followed (likely updated | ||
after we get HackerOne up and running). | ||
|
||
* Respond to the requestor 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-Node.js-vulnerabilities) | ||
and return the CVE number to the requestor (along with the request | ||
to keep it confidential until the vulnerability is announced) | ||
* If a CVE is not appropriate then respond to the requestor | ||
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 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 issue in the security issue being used to discuss the | ||
vulnerability, associate the CVE to that vulnerability. This is most | ||
commonly done by including it is the draft for the announcement that | ||
will go out once the associated security releases are availble. | ||
* 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. | ||
* 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 availble. | ||
|