@@ -43,191 +43,136 @@ The current security stewards are documented in the main Node.js
4343
4444##Planning
4545
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 ` .
7782
7883##Announcement (one week in advance of the planned release)
7984
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,
122- Bryan English)
123-
124- * [ ] CC` oss-security@lists.openwall.com ` on pre-release
125-
126- The google groups UI does not support adding a CC, until we figure
127- out a better way, forward the email you receive to
128- ` oss-security@lists.openwall.com ` as a CC.
129-
130- * [ ] Post in the[ nodejs-social channel] [ ]
131- in the OpenJS slack asking for amplification of the blog post.
132-
133- ``` text
134- Security release pre-alert:
135-
136- We will release new versions of <add versions> release lines on or shortly
137- after Day Month Date, Year in order to address:
138-
139- - # high severity issues
140- - # moderate severity issues
141-
142- https://nodejs.org/en/blog/vulnerability/month-year-security-releases/
143- ```
144-
145- 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
93+ issues and emails needed for the notifications.
94+ * [ docker-node] ( https://github.com/nodejs/docker-node/issues )
95+ * [ build-wg] ( https://github.com/nodejs/build/issues )
96+ * [ ] (Not yet automatic - do this manually)[ Google Groups] ( https://groups.google.com/g/nodejs-sec )
97+ * Email: notify< oss-security@lists.openwall.com >
98+ * [ ] (Not yet automatic - do this manually) Post in the nodejs-social channel
99+ in the OpenJS slack asking for amplification of the blog post.
100+
101+ ``` text
102+ Security release pre-alert:
103+
104+ We will release new versions of <add versions> release lines on or shortly
105+ after Day Month Date, Year in order to address:
106+
107+ * # high severity issues
108+ * # moderate severity issues
109+
110+ https://nodejs.org/en/blog/vulnerability/month-year-security-releases/
111+ ```
112+
113+ We specifically ask that collaborators other than the releasers and security
114+ steward working on the security release do not tweet or publicize the release
115+ until the tweet from Node.js goes out. We have often
116+ seen tweets sent out before the release is
117+ complete, which may confuse those waiting for the release and take
118+ away from the work the releasers have put into shipping the release.
119+
120+ If the security release will only contain an OpenSSL update, consider
121+ adding the following to the pre-release announcement:
122+
123+ ```text
124+ Since this security release will only include updates for OpenSSL, if you're using
125+ a Node.js version which is part of a distribution that uses a system
126+ installed OpenSSL, this Node.js security update may not concern you, instead,
127+ you may need to update your system OpenSSL libraries. Please check the
128+ security announcements for more information.
129+ ```
168130
169131##Release day
170132
171- * [ ] [ Lock CI] ( https://github.com/nodejs/build/blob/HEAD/doc/jenkins-guide.md#before-the-release )
172-
173- * [ ] The releaser(s) run the release process to completion.
174-
175- * [ ] [ Unlock CI] ( https://github.com/nodejs/build/blob/HEAD/doc/jenkins-guide.md#after-the-release )
176-
177- * [ ] Post-release announcement to Nodejs.org blog:_ ** LINK TO BLOG POST** _
178- * (Re-PR the pre-approved branch from nodejs-private/nodejs.org-private to
179- nodejs/nodejs.org)
180-
181- * [ ] Post-release announcement in reply[ email] [ ] :_ ** LINK TO EMAIL** _
182- * CC:` oss-security@lists.openwall.com `
183- * 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.
196-
197- https://nodejs.org/en/blog/vulnerability/month-year-security-releases/
198- ```
199-
200- * [ ] 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:
148+ * [ ] Slack:` #nodejs-social `
149+ * [ ] [ docker-node] ( https://github.com/nodejs/docker-node/issues )
150+ * [ ] [ build-wg] ( https://github.com/nodejs/build/issues )
151+ * [ ] Email: notify[ Google Groups] ( https://groups.google.com/g/nodejs-sec )
152+ * Forward to< oss-security@lists.openwall.com >
153+
154+ ##Post-Release
155+
156+ * [ ] 1\. ** Merge the Next Security Release PR:**
157+ * 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
211169 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+
213171 page.
214172![ screenshot of HackerOne CVE form] ( https://github.com/nodejs/node/assets/26234614/e22e4f33-7948-4dd2-952e-2f9166f5568d )
215-
216- * [ ] PR machine-readable JSON descriptions of the vulnerabilities to the
217- [ core] ( https://github.com/nodejs/security-wg/tree/HEAD/vuln/core )
218- vulnerability DB._ ** LINK TO PR** _
219- * For each vulnerability add a` #.json ` file, one can copy an existing
220- [ json] ( https://github.com/nodejs/security-wg/blob/0d82062d917cb9ddab88f910559469b2b13812bf/vuln/core/78.json )
221- file, and increment the latest created file number and use that as the name
222- of the new file to be added. For example,` 79.json ` .
223-
224- * [ ] Close this issue
225-
226- * [ ] Make sure the PRs for the vulnerabilities are closed.
227-
228- * [ ] PR in that you stewarded the release in
229- [ Security release stewards] ( https://github.com/nodejs/node/blob/HEAD/doc/contributing/security-release-process.md#security-release-stewards ) .
230- 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 )
231176
232177##Adding a security revert option
233178
@@ -298,8 +243,4 @@ The steps to correct CVE information are:
298243* Include all the details that need updating within the form
299244* Submit the request
300245
301- [ H1 CVE requests ] :https://hackerone.com/nodejs/cve_requests
302- [ docker-node ] :https://github.com/nodejs/docker-node/issues
303- [ email ] :https://groups.google.com/forum/#!forum/nodejs-sec
304- [ nodejs-social channel ] :https://openjs-foundation.slack.com/archives/C0142A39BNE
305- [ nodejs/build ] :https://github.com/nodejs/build/issues
246+ [ security-release ] :https://github.com/nodejs-private/security-release