-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc: add initial draft of CVE management process #60
Changes from 2 commits
211f3a3
68a9372
8cb697b
367d1ba
8bb9ad3
0c2adf5
4f21daf
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,123 @@ | ||
# Node.js CVE management process | ||
|
||
The Node.js project acts as a Commonn Vulnerabilities and Exposures (CVE) | ||
Numbering Authority (CNA). 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 thir party modules. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Only for Core and Foundation projects or userland modules also? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It is only for Core and Foundation projects. That line tries to say that userland modules are excluded for now. Once we are comfortable with that scope we will consider expanding. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "third" |
||
|
||
More detailed information about the CNA program is available in | ||
https://cve.mitre.org/cve/cna/CNA_Rules_v1.1.pdf | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Perhaps create a link here? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done |
||
|
||
# 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. | ||
**cna-discussion-list** | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "@iojs.org"? |
||
|
||
# CNA management processes | ||
|
||
## CVE Block management | ||
|
||
The CNA program allows the Node.js team to request a block of CVE's in | ||
advance. These CVE's are managed in an issue within the private Node.js | ||
security repo (https://github.com/nodejs/security). Each year there | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe just make "security repo" a link and drop the explicit URL. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done |
||
will be an issue in that repo titled: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I recommend that we create a separate dedicated repository under the nodejs-private github organization for CVE management. Discussion of assignments would be in issues, actual assignments done as PRs against a master record in the repository. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That would be ok with me as well, just was not sure if we wanted to create additional repos |
||
|
||
``` | ||
CVE Block for XXXX | ||
``` | ||
|
||
were XXXX is the year (for example `CVE Block for 2017`). | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. were -> where There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done |
||
|
||
This issue will have the following sections: | ||
|
||
* Available | ||
* Pending | ||
* Announced | ||
|
||
|
||
When a new block of CVEs is received from Mitre they will be listed under | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Extra space after CVEs There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fixed |
||
the `Available` secion. | ||
|
||
These CVE's will be moved from the Available to Pending and Announced | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. CVEs vs. CVE's. Can you use one or the other consistently. I assume it's CVEs since it is not possessive. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fixed |
||
as outlined in the section titled `CVE Management process`. | ||
|
||
In addition, when moving a CVE from Available such that there are less | ||
than 2 remaning CVE's a new block must be requested as follows: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 2 remaning -> two remaining There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done |
||
|
||
* 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. | ||
|
||
**Note**: When making any changes in the issue, first add a comment | ||
indicating the change being made. | ||
|
||
|
||
## 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 hacker one up and running). | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. hacker one -> HackerOne There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done |
||
|
||
* Respond to the requestor indicating that we have the request | ||
and will review soon. | ||
* Open an issue in the security repo for the request | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Missing a period at the end of the line. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fixed |
||
* Review the request. | ||
* If a CVE is appropriate then assign the | ||
CVE as outline in the section titled | ||
`CVE Management processes for Node.js vulnerabilities` and | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should this link to the section? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done |
||
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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe just link this and drop the explicit URL. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done |
||
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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Link and drop the explicit URL? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done |
||
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. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having
Common Vulnerabilities and Exposures (CVE) Numbering Authority (CNA)
be a link would be good.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good idea.