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 | 2023-Aug-09 | 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 * Use the "summary" feature in HackerOne to sync post-release content 60 and CVE requests. Example [2038134](https://hackerone.com/bugs?subject=nodejs\&report_id=2038134) 61 * Ask the HackerOne reporter if they would like to be credited on the 62 security release blog page: 63 ```text 64 Thank you to <name> for reporting this vulnerability. 65 ``` 66 67* [ ] Get agreement on the planned date for the release: _**RELEASE DATE**_ 68 69* [ ] Get release team volunteers for all affected lines: 70 * v12.x: _**NAME of RELEASER(S)**_ 71 * ... other lines, if multiple releasers 72 73## Announcement (one week in advance of the planned release) 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 * Use the "summary" feature in HackerOne to create a description for the 85 CVE and the post release announcement. 86 Example [2038134](https://hackerone.com/bugs?subject=nodejs\&report_id=2038134) 87 * Make sure that dependent libraries have CVEs for their issues. We should 88 only create CVEs for vulnerabilities in Node.js itself. This is to avoid 89 having duplicate CVEs for the same vulnerability. 90 * Described in the pre/post announcements 91 92* [ ] Pre-release announcement to nodejs.org blog: _**LINK TO BLOG**_ 93 (Re-PR the pre-approved branch from nodejs-private/nodejs.org-private to 94 nodejs/nodejs.org) 95 96 If the security release will only contain an OpenSSL update consider 97 adding the following to the pre-release announcement: 98 99 ```text 100 Since this security release will only include updates for OpenSSL, if you're using 101 a Node.js version which is part of a distribution which uses a system 102 installed OpenSSL, this Node.js security update might not concern you. You may 103 instead need to update your system OpenSSL libraries, please check the 104 security announcements for the distribution. 105 ``` 106 107* [ ] Pre-release announcement [email][]: _**LINK TO EMAIL**_ 108 * Subject: `Node.js security updates for all active release lines, Month Year` 109 * Body: 110 ```text 111 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 112 For more information see: https://nodejs.org/en/blog/vulnerability/month-year-security-releases/ 113 ``` 114 (Get access from existing manager: Matteo Collina, Rodd Vagg, Michael Dawson, 115 Bryan English) 116 117* [ ] CC `oss-security@lists.openwall.com` on pre-release 118 119The google groups UI does not support adding a CC, until we figure 120out a better way, forward the email you receive to 121`oss-security@lists.openwall.com` as a CC. 122 123* [ ] Send a message to `#nodejs-social` in OpenJS Foundation slack 124 125 ```text 126 Security release pre-alert: 127 128 We will release new versions of <add versions> release lines on or shortly 129 after Day Month Date, Year in order to address: 130 131 - # high severity issues 132 - # moderate severity issues 133 134 https://nodejs.org/en/blog/vulnerability/month-year-security-releases/ 135 ``` 136 137 We specifically ask that collaborators other than the releasers and security 138 steward working on the security release do not tweet or publicise the release 139 until the tweet from the Node.js twitter handle goes out. We have often 140 seen tweets sent out before the release and associated announcements are 141 complete which may confuse those waiting for the release and also takes 142 away from the work the releasers have put into shipping the releases. 143 144* [ ] Request releaser(s) to start integrating the PRs to be released. 145 146* [ ] Notify [docker-node][] of upcoming security release date: _**LINK**_ 147 ```text 148 Heads up of Node.js security releases Day Month Year 149 150 As per the Node.js security release process this is the FYI that there is going to be a security release Day Month Year 151 ``` 152 153* [ ] Notify build-wg of upcoming security release date by opening an issue 154 in [nodejs/build][] to request WG members are available to fix any CI issues. 155 ```text 156 Heads up of Node.js security releases Day Month Year 157 158 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. 159 ``` 160 161## Release day 162 163* [ ] [Lock CI](https://github.com/nodejs/build/blob/HEAD/doc/jenkins-guide.md#before-the-release) 164 165* [ ] The releaser(s) run the release process to completion. 166 167* [ ] [Unlock CI](https://github.com/nodejs/build/blob/HEAD/doc/jenkins-guide.md#after-the-release) 168 169* [ ] Post-release announcement to Nodejs.org blog: _**LINK TO BLOG POST**_ 170 * (Re-PR the pre-approved branch from nodejs-private/nodejs.org-private to 171 nodejs/nodejs.org) 172 173* [ ] Post-release announcement in reply [email][]: _**LINK TO EMAIL**_ 174 * CC: `oss-security@lists.openwall.com` 175 * Subject: `Node.js security updates for all active release lines, Month Year` 176 * Body: 177 ```text 178 The Node.js project has now released new versions of all supported release lines. 179 For more information see: https://nodejs.org/en/blog/vulnerability/month-year-security-releases/ 180 ``` 181 182* [ ] Create a new issue in [nodejs/tweet][] 183 ```text 184 Security release: 185 186 New security releases are now available for versions <add versions> of Node.js. 187 188 https://nodejs.org/en/blog/vulnerability/month-year-security-releases/ 189 ``` 190 191* [ ] Comment in [docker-node][] issue that release is ready for integration. 192 The docker-node team will build and release docker image updates. 193 194* [ ] For every H1 report resolved: 195 * Close as Resolved 196 * Request Disclosure 197 * Request publication of [H1 CVE requests][] 198 * (Check that the "Version Fixed" field in the CVE is correct, and provide 199 links to the release blogs in the "Public Reference" section) 200 201* [ ] PR machine-readable JSON descriptions of the vulnerabilities to the 202 [core](https://github.com/nodejs/security-wg/tree/HEAD/vuln/core) 203 vulnerability DB. _**LINK TO PR**_ 204 * For each vulnerability add a `#.json` file, one can copy an existing 205 [json](https://github.com/nodejs/security-wg/blob/0d82062d917cb9ddab88f910559469b2b13812bf/vuln/core/78.json) 206 file, and increment the latest created file number and use that as the name 207 of the new file to be added. For example, `79.json`. 208 209* [ ] Close this issue 210 211* [ ] Make sure the PRs for the vulnerabilities are closed. 212 213* [ ] PR in that you stewarded the release in 214 [Security release stewards](https://github.com/nodejs/node/blob/HEAD/doc/contributing/security-release-process.md#security-release-stewards). 215 If necessary add the next rotation of the steward rotation. 216 217## When things go wrong 218 219### Incomplete fixes 220 221When a CVE is reported as fixed in a security release and it turns out that the 222fix was incomplete, a new CVE should be used to cover subsequent fix. This 223is best practice and avoids confusion that might occur if people believe 224they have patched the original CVE by updating their Node.js version and 225then we later change the `fixed in` value for the CVE. 226 227### Updating CVEs 228 229The steps to correct CVE information are: 230 231* Go to the “CVE IDs” section in your program 232 sections (<https://hackerone.com/nodejs/cve_requests>) 233* Click the “Request a CVE ID” button 234* Enter the CVE ID that needs to be updated 235* Include all the details that need updating within the form 236* Submit the request 237 238[H1 CVE requests]: https://hackerone.com/nodejs/cve_requests 239[docker-node]: https://github.com/nodejs/docker-node/issues 240[email]: https://groups.google.com/forum/#!forum/nodejs-sec 241[nodejs/build]: https://github.com/nodejs/build/issues 242[nodejs/tweet]: https://github.com/nodejs/tweet/issues 243