1# Security release process 2 3The security release process covers the steps required to plan/implement a 4security release. This document is copied into the description of the Next 5Security Release and used to track progress on the release. It contains _**TEXT 6LIKE THIS**_ which will be replaced during the release process with the 7information described. 8 9## Security release stewards 10 11For each security release, a security steward will take ownership for 12coordinating the steps outlined in this process. Security stewards 13are nominated through an issue in the TSC repository and approved 14through the regular TSC consensus process. Once approved, they 15are given access to all of the resources needed to carry out the 16steps listed in the process as outlined in 17[security steward on/off boarding](security-steward-on-off-boarding.md). 18 19The current security stewards are documented in the main Node.js 20[README.md](https://github.com/nodejs/node#security-release-stewards). 21 22| Company | Person | Release Date | 23| ------------ | --------------- | ------------ | 24| NearForm | Matteo | 2021-Oct-12 | 25| Datadog | Bryan | 2022-Jan-10 | 26| RH and IBM | Joe | 2022-Mar-18 | 27| NearForm | Matteo / Rafael | 2022-Jul-07 | 28| Datadog | Vladimir | 2022-Sep-23 | 29| NodeSource | Juan | 2022-Nov-04 | 30| RH and IBM | Michael | 2023-Feb-16 | 31| NearForm | Rafael | 2023-Jun-20 | 32| NearForm | Rafael | | 33| Datadog | Bryan | | 34| IBM | Joe | | 35| Platformatic | Matteo | | 36| NodeSource | Juan | | 37| Red Hat | Michael | | 38 39## Planning 40 41* [ ] Open an [issue](https://github.com/nodejs-private/node-private) titled 42 `Next Security Release`, and put this checklist in the description. 43 44* [ ] Get agreement on the list of vulnerabilities to be addressed: 45 * _**H1 REPORT LINK**_: _**DESCRIPTION**_ (_**CVE or H1 CVE request link**_) 46 * v10.x, v12.x: _**LINK to PR URL**_ 47 * ... 48 49* [ ] PR release announcements in [private](https://github.com/nodejs-private/nodejs.org-private): 50 * (Use previous PRs as templates. Don't forget to update the site banner and 51 the date in the slug so that it will move to the top of the blog list.) 52 * (Consider using a [Vulnerability Score System](https://www.first.org/cvss/calculator/3.1) 53 to identify severity of each report) 54 * Share the patch with the reporter when applicable. 55 It will increase the fix accuracy. 56 * [ ] pre-release: _**LINK TO PR**_ 57 * [ ] post-release: _**LINK TO PR**_ 58 * List vulnerabilities in order of descending severity 59 * Ask the HackerOne reporter if they would like to be credited on the 60 security release blog page: 61 ```text 62 Thank you to <name> for reporting this vulnerability. 63 ``` 64 65* [ ] Get agreement on the planned date for the release: _**RELEASE DATE**_ 66 67* [ ] Get release team volunteers for all affected lines: 68 * v12.x: _**NAME of RELEASER(S)**_ 69 * ... other lines, if multiple releasers 70 71## Announcement (one week in advance of the planned release) 72 73* [ ] Verify that GitHub Actions are working as normal: <https://www.githubstatus.com/>. 74 75* [ ] Check that all vulnerabilities are ready for release integration: 76 * PRs against all affected release lines or cherry-pick clean 77 * Approved 78 * (optional) Approved by the reporter 79 * Build and send the binary to the reporter according to its architecture 80 and ask for a review. This step is important to avoid insufficient fixes 81 between Security Releases. 82 * Pass `make test` 83 * Have CVEs 84 * Make sure that dependent libraries have CVEs for their issues. We should 85 only create CVEs for vulnerabilities in Node.js itself. This is to avoid 86 having duplicate CVEs for the same vulnerability. 87 * Described in the pre/post announcements 88 89* [ ] Pre-release announcement to nodejs.org blog: _**LINK TO BLOG**_ 90 (Re-PR the pre-approved branch from nodejs-private/nodejs.org-private to 91 nodejs/nodejs.org) 92 93 If the security release will only contain an OpenSSL update consider 94 adding the following to the pre-release announcement: 95 96 ```text 97 Since this security release will only include updates for OpenSSL, if you're using 98 a Node.js version which is part of a distribution which uses a system 99 installed OpenSSL, this Node.js security update might not concern you. You may 100 instead need to update your system OpenSSL libraries, please check the 101 security announcements for the distribution. 102 ``` 103 104* [ ] Pre-release announcement [email][]: _**LINK TO EMAIL**_ 105 * Subject: `Node.js security updates for all active release lines, Month Year` 106 * Body: 107 ```text 108 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 109 For more information see: https://nodejs.org/en/blog/vulnerability/month-year-security-releases/ 110 ``` 111 (Get access from existing manager: Matteo Collina, Rodd Vagg, Michael Dawson, 112 Bryan English) 113 114* [ ] CC `oss-security@lists.openwall.com` on pre-release 115 116The google groups UI does not support adding a CC, until we figure 117out a better way, forward the email you receive to 118`oss-security@lists.openwall.com` as a CC. 119 120* [ ] Create a new issue in [nodejs/tweet][] 121 122 ```text 123 Security release pre-alert: 124 125 We will release new versions of <add versions> release lines on or shortly 126 after Day Month Date, Year in order to address: 127 128 - # high severity issues 129 - # moderate severity issues 130 131 https://nodejs.org/en/blog/vulnerability/month-year-security-releases/ 132 ``` 133 134 We specifically ask that collaborators other than the releasers and security 135 steward working on the security release do not tweet or publicise the release 136 until the tweet from the Node.js twitter handle goes out. We have often 137 seen tweets sent out before the release and associated announcements are 138 complete which may confuse those waiting for the release and also takes 139 away from the work the releasers have put into shipping the releases. 140 141* [ ] Request releaser(s) to start integrating the PRs to be released. 142 143* [ ] Notify [docker-node][] of upcoming security release date: _**LINK**_ 144 ```text 145 Heads up of Node.js security releases Day Month Year 146 147 As per the Node.js security release process this is the FYI that there is going to be a security release Day Month Year 148 ``` 149 150* [ ] Notify build-wg of upcoming security release date by opening an issue 151 in [nodejs/build][] to request WG members are available to fix any CI issues. 152 ```text 153 Heads up of Node.js security releases Day Month Year 154 155 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. 156 ``` 157 158## Release day 159 160* [ ] [Lock CI](https://github.com/nodejs/build/blob/HEAD/doc/jenkins-guide.md#before-the-release) 161 162* [ ] The releaser(s) run the release process to completion. 163 164* [ ] [Unlock CI](https://github.com/nodejs/build/blob/HEAD/doc/jenkins-guide.md#after-the-release) 165 166* [ ] Post-release announcement to Nodejs.org blog: _**LINK TO BLOG POST**_ 167 * (Re-PR the pre-approved branch from nodejs-private/nodejs.org-private to 168 nodejs/nodejs.org) 169 170* [ ] Post-release announcement in reply [email][]: _**LINK TO EMAIL**_ 171 * CC: `oss-security@lists.openwall.com` 172 * Subject: `Node.js security updates for all active release lines, Month Year` 173 * Body: 174 ```text 175 The Node.js project has now released new versions of all supported release lines. 176 For more information see: https://nodejs.org/en/blog/vulnerability/month-year-security-releases/ 177 ``` 178 179* [ ] Create a new issue in [nodejs/tweet][] 180 ```text 181 Security release: 182 183 New security releases are now available for versions <add versions> of Node.js. 184 185 https://nodejs.org/en/blog/vulnerability/month-year-security-releases/ 186 ``` 187 188* [ ] Comment in [docker-node][] issue that release is ready for integration. 189 The docker-node team will build and release docker image updates. 190 191* [ ] For every H1 report resolved: 192 * Close as Resolved 193 * Request Disclosure 194 * Request publication of [H1 CVE requests][] 195 * (Check that the "Version Fixed" field in the CVE is correct, and provide 196 links to the release blogs in the "Public Reference" section) 197 198* [ ] PR machine-readable JSON descriptions of the vulnerabilities to the 199 [core](https://github.com/nodejs/security-wg/tree/HEAD/vuln/core) 200 vulnerability DB. _**LINK TO PR**_ 201 * For each vulnerability add a `#.json` file, one can copy an existing 202 [json](https://github.com/nodejs/security-wg/blob/0d82062d917cb9ddab88f910559469b2b13812bf/vuln/core/78.json) 203 file, and increment the latest created file number and use that as the name 204 of the new file to be added. For example, `79.json`. 205 206* [ ] Close this issue 207 208* [ ] Make sure the PRs for the vulnerabilities are closed. 209 210* [ ] PR in that you stewarded the release in 211 [Security release stewards](https://github.com/nodejs/node/blob/HEAD/doc/contributing/security-release-process.md#security-release-stewards). 212 If necessary add the next rotation of the steward rotation. 213 214## When things go wrong 215 216### Incomplete fixes 217 218When a CVE is reported as fixed in a security release and it turns out that the 219fix was incomplete, a new CVE should be used to cover subsequent fix. This 220is best practice and avoids confusion that might occur if people believe 221they have patched the original CVE by updating their Node.js version and 222then we later change the `fixed in` value for the CVE. 223 224### Updating CVEs 225 226The steps to correct CVE information are: 227 228* Go to the “CVE IDs” section in your program 229 sections (<https://hackerone.com/nodejs/cve_requests>) 230* Click the “Request a CVE ID” button 231* Enter the CVE ID that needs to be updated 232* Include all the details that need updating within the form 233* Submit the request 234 235[H1 CVE requests]: https://hackerone.com/nodejs/cve_requests 236[docker-node]: https://github.com/nodejs/docker-node/issues 237[email]: https://groups.google.com/forum/#!forum/nodejs-sec 238[nodejs/build]: https://github.com/nodejs/build/issues 239[nodejs/tweet]: https://github.com/nodejs/tweet/issues 240