You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: doc/contributing/security-release-process.md
+122-181
Original file line number
Diff line number
Diff line change
@@ -43,191 +43,136 @@ The current security stewards are documented in the main Node.js
43
43
44
44
## Planning
45
45
46
-
*[ ] Open an [issue](https://github.com/nodejs-private/node-private) titled
47
-
`Next Security Release`, and put this checklist in the description.
48
-
49
-
*[ ] Get agreement on the list of vulnerabilities to be addressed:
50
-
*_**H1 REPORT LINK**_: _**DESCRIPTION**_ (_**CVE or H1 CVE request link**_)
51
-
* v10.x, v12.x: _**LINK to PR URL**_
52
-
* ...
53
-
54
-
*[ ] PR release announcements in [private](https://github.com/nodejs-private/nodejs.org-private):
55
-
* (Use previous PRs as templates. Don't forget to update the site banner and
56
-
the date in the slug so that it will move to the top of the blog list.)
57
-
* (Consider using a [Vulnerability Score System](https://www.first.org/cvss/calculator/3.1)
58
-
to identify severity of each report)
59
-
* Share the patch with the reporter when applicable.
60
-
It will increase the fix accuracy.
61
-
*[ ] pre-release: _**LINK TO PR**_
62
-
*[ ] post-release: _**LINK TO PR**_
63
-
* List vulnerabilities in order of descending severity
64
-
* Use the "summary" feature in HackerOne to sync post-release content
65
-
and CVE requests. Example [2038134](https://hackerone.com/bugs?subject=nodejs\&report_id=2038134)
66
-
* Ask the HackerOne reporter if they would like to be credited on the
67
-
security release blog page:
68
-
```text
69
-
Thank you to <name> for reporting this vulnerability.
70
-
```
71
-
72
-
* [ ] Get agreement on the planned date for the release: _**RELEASE DATE**_
73
-
74
-
* [ ] Get release team volunteers for all affected lines:
75
-
* v12.x: _**NAME of RELEASER(S)**_
76
-
* ... other lines, if multiple releasers
46
+
*[ ] 1\.**Generating Next Security Release PR**
47
+
* Run `git node security --start` inside [security-release][] repository.
48
+
* This command generates a new `vulnerabilities.json` file with HackerOne
49
+
reports chosen to be released in the `security-release/next-security-release`
50
+
folder.
51
+
* It also creates the pull request used to manage the security release.
52
+
53
+
*[ ] 2\.**Review of Reports:**
54
+
* Reports can be added or removed using the following commands:
55
+
* Use the "summary" feature in HackerOne. Example [2038134](https://hackerone.com/reports/2038134)
56
+
*`git node security --add-report=report_id`
57
+
*`git node security --remove-report=report_id`
58
+
59
+
*[ ] 3\.**Assigning Severity and Writing Team Summary:**
60
+
*[ ] Assign a severity and write a team summary on HackerOne for the reports
61
+
chosen in the `vulnerabilities.json`.
62
+
* Run `git node security --sync` to update severity and summary in
63
+
`vulnerabilities.json`.
64
+
65
+
*[ ] 4\.**Requesting CVEs:**
66
+
* Request CVEs for the reports with `git node security --request-cve`.
67
+
* Make sure to have a green CI before requesting a CVE.
68
+
69
+
*[ ] 5\.**Choosing or Updating Release Date:**
70
+
* Get agreement on the planned date for the release.
71
+
*[ ] Use `git node security --update-date=YYYY/MM/DD` to choose or update the
72
+
release date.
73
+
* This allows flexibility in postponing the release if needed.
74
+
75
+
*[ ] 6\.**Get release volunteers:**
76
+
* Get volunteers for the upcoming security release on the affected release
77
+
lines.
78
+
79
+
*[ ] 7\.**Preparing Pre and Post Release Blog Posts:**
80
+
*[ ] Create a pre-release blog post using `git node security --pre-release`.
81
+
*[ ] Create a post-release blog post using `git node security --post-release`.
77
82
78
83
## Announcement (one week in advance of the planned release)
79
84
80
-
* [ ] Check that all vulnerabilities are ready for release integration:
81
-
* PRs against all affected release lines or cherry-pick clean
82
-
* PRs with breaking changes have a
83
-
[--security-revert](#Adding-a-security-revert-option) option if possible.
84
-
* Approved
85
-
* (optional) Approved by the reporter
86
-
* Build and send the binary to the reporter according to its architecture
87
-
and ask for a review. This step is important to avoid insufficient fixes
88
-
between Security Releases.
89
-
* Pass `make test`
90
-
* Have CVEs
91
-
* Use the "summary" feature in HackerOne to create a description for the
92
-
CVE and the post release announcement.
93
-
Example [2038134](https://hackerone.com/bugs?subject=nodejs\&report_id=2038134)
94
-
* Make sure that dependent libraries have CVEs for their issues. We should
95
-
only create CVEs for vulnerabilities in Node.js itself. This is to avoid
96
-
having duplicate CVEs for the same vulnerability.
97
-
* Described in the pre/post announcements
98
-
99
-
* [ ] Pre-release announcement to nodejs.org blog: _**LINK TO BLOG**_
100
-
(Re-PR the pre-approved branch from nodejs-private/nodejs.org-private to
101
-
nodejs/nodejs.org)
102
-
103
-
If the security release will only contain an OpenSSL update consider
104
-
adding the following to the pre-release announcement:
105
-
106
-
```text
107
-
Since this security release will only include updates for OpenSSL, if you're using
108
-
a Node.js version which is part of a distribution which uses a system
109
-
installed OpenSSL, this Node.js security update might not concern you. You may
110
-
instead need to update your system OpenSSL libraries, please check the
111
-
security announcements for the distribution.
112
-
```
113
-
114
-
*[ ] Pre-release announcement [email][]: _**LINK TO EMAIL**_
115
-
* Subject: `Node.js security updates for all active release lines, Month Year`
116
-
* Body:
117
-
```text
118
-
The Node.js project will release new versions of all supported release lines on or shortly after Day of week, Month Day of Month, Year
119
-
For more information see: https://nodejs.org/en/blog/vulnerability/month-year-security-releases/
120
-
```
121
-
(Get access from existing manager: Matteo Collina, Rodd Vagg, Michael Dawson,
We specifically ask that collaborators other than the releasers and security
146
-
steward working on the security release do not tweet or publicise the release
147
-
until the tweet from the Node.js twitter handle goes out. We have often
148
-
seen tweets sent out before the release and associated announcements are
149
-
complete which may confuse those waiting for the release and also takes
150
-
away from the work the releasers have put into shipping the releases.
151
-
152
-
*[ ] Request releaser(s) to start integrating the PRs to be released.
153
-
154
-
*[ ] Notify [docker-node][] of upcoming security release date: _**LINK**_
155
-
```text
156
-
Heads up of Node.js security releases Day Month Year
157
-
158
-
As per the Node.js security release process this is the FYI that there is going to be a security release Day Month Year
159
-
```
160
-
161
-
*[ ] Notify build-wg of upcoming security release date by opening an issue
162
-
in [nodejs/build][] to request WG members are available to fix any CI issues.
163
-
```text
164
-
Heads up of Node.js security releases Day Month Year
165
-
166
-
As per security release process this is a heads up that there will be security releases Day Month Year and we'll need people from build to lock/unlock ci and to support and build issues we see.
167
-
```
85
+
*[ ] 1\.**Publish Pre-Release Blog Post:**
86
+
* Publish the pre-release blog post on the `nodejs/nodejs.org` repository.
87
+
88
+
*[ ] 2\.**Send Pre-Release Announcement:**
89
+
* Notify the community about the upcoming security release:
90
+
91
+
*[ ]`git node security --notify-pre-release`
92
+
Except for those noted in the list below, this will create automatically the
* Subject: `Node.js security updates for all active release lines, Month Year`
184
-
* Body:
185
-
```text
186
-
The Node.js project has now released new versions of all supported release lines.
187
-
For more information see: https://nodejs.org/en/blog/vulnerability/month-year-security-releases/
188
-
```
189
-
190
-
*[ ] Post in the [nodejs-social channel][]
191
-
in the OpenJS slack asking for amplification of the blog post.
192
-
```text
193
-
Security release:
194
-
195
-
New security releases are now available for versions <add versions> of Node.js.
*[ ] Comment in [docker-node][] issue that release is ready for integration.
201
-
The docker-node team will build and release docker image updates.
202
-
203
-
*[ ] For every H1 report resolved:
204
-
* Close as Resolved
205
-
* Request Disclosure
206
-
* Request publication of [H1 CVE requests][]
207
-
* (Check that the "Version Fixed" field in the CVE is correct, and provide
208
-
links to the release blogs in the "Public Reference" section)
209
-
* In case the reporter doesn't accept the disclosure follow this process:
210
-
* Remove the original report reference within the reference text box and
133
+
*[ ] 1\.**Lock down the CI:**
134
+
* Lock down the CI to prevent public access to the CI machines, ping a member of `@nodejs/jenkins-admins`.
135
+
136
+
*[ ] 2\.**Release:**
137
+
* Verify the CI is green on all release proposals (test-V8, CITGM, etc).
138
+
* Follow the [release process](https://github.com/nodejs/node/blob/main/doc/contributing/releases.md).
139
+
140
+
*[ ] 3\.**Unlock the CI:**
141
+
* Unlock the CI to allow public access to the CI machines, ping a member of `@nodejs/jenkins-admins`.
142
+
143
+
*[ ] 4\.**Publish Post-Release Blog Post:**
144
+
* Publish the post-release blog post on the `nodejs/nodejs.org` repository.
145
+
146
+
*[ ] 5\.**Notify the community:**
147
+
* Notify the community that the security release has gone out:
* This involves moving the `vulnerabilities.json` file from
158
+
`security-release/next-security-release` to the `security-release/YYYY-MM-DD`
159
+
folder and merging the PR.
160
+
161
+
*[ ] 2\.**Cleanup:**
162
+
*[ ] Close PRs and backports.
163
+
*[ ] Close HackerOne reports:
164
+
* Close Resolved
165
+
* Request Disclosure
166
+
* Request publication of H1 CVE requests
167
+
* In case the reporter doesn't accept the disclosure follow this process:
168
+
Remove the original report reference within the reference text box and
211
169
insert the public URL you would like to be attached to this CVE.
212
-
* Then uncheck the Public Disclosure on HackerOne box at the bottom of the
170
+
Then uncheck the Public Disclosure on HackerOne box at the bottom of the
213
171
page.
214
172
215
-
216
-
*[ ] PR machine-readable JSON descriptions of the vulnerabilities to the
If necessary add the next rotation of the steward rotation.
173
+
*[ ] PR machine-readable JSON descriptions of the vulnerabilities to the [core](https://github.com/nodejs/security-wg/tree/HEAD/vuln/core)
174
+
vulnerability DB.
175
+
*[ ] Add yourself as a steward in the [Security Release Stewards](https://github.com/nodejs/node/blob/HEAD/doc/contributing/security-release-process.md#security-release-stewards)
231
176
232
177
## Adding a security revert option
233
178
@@ -298,8 +243,4 @@ The steps to correct CVE information are:
298
243
* Include all the details that need updating within the form
0 commit comments