doc: update security-release process to automated one

doc/contributing/security-release-process.md

@@ -43,191 +43,118 @@ The current security stewards are documented in the main Node.js
 
 ## Planning
 
-* [ ] Open an [issue](https://github.com/nodejs-private/node-private) titled
-  `Next Security Release`, and put this checklist in the description.
-
-* [ ] Get agreement on the list of vulnerabilities to be addressed:
-  * _**H1 REPORT LINK**_: _**DESCRIPTION**_ (_**CVE or H1 CVE request link**_)
-    * v10.x, v12.x: _**LINK to PR URL**_
-  * ...
-
-* [ ] PR release announcements in [private](https://github.com/nodejs-private/nodejs.org-private):
-  * (Use previous PRs as templates. Don't forget to update the site banner and
-    the date in the slug so that it will move to the top of the blog list.)
-  * (Consider using a [Vulnerability Score System](https://www.first.org/cvss/calculator/3.1)
-    to identify severity of each report)
-  * Share the patch with the reporter when applicable.
-    It will increase the fix accuracy.
-  * [ ] pre-release: _**LINK TO PR**_
-  * [ ] post-release: _**LINK TO PR**_
-    * List vulnerabilities in order of descending severity
-    * Use the "summary" feature in HackerOne to sync post-release content
-      and CVE requests. Example [2038134](https://hackerone.com/bugs?subject=nodejs\&report_id=2038134)
-    * Ask the HackerOne reporter if they would like to be credited on the
-      security release blog page:
-      ```text
-      Thank you to <name> for reporting this vulnerability.
-      ```
-
-* [ ] Get agreement on the planned date for the release: _**RELEASE DATE**_
-
-* [ ] Get release team volunteers for all affected lines:
-  * v12.x: _**NAME of RELEASER(S)**_
-  * ... other lines, if multiple releasers
+1. **Generating Next Security Release PR**
+   * Run `git node security --start` inside [security-release][] repository.
+   * This command generates a new `vulnerabilities.json` file with HackerOne
+     reports chosen to be released in the `security-release/next-security-release`
+     folder.
+   * It also creates the Pull Request used to manage the security release.
+
+2. **Review of Reports:**
+   * Reports can be added or removed using the following commands:
+     * Use the "summary" feature in HackerOne. Example [2038134](https://hackerone.com/bugs?subject=nodejs\&report_id=2038134)
+     * `git node security --add-report=report_id`
+     * `git node security --remove-report=report_id`
+
+3. **Assigning Severity and Writing Team Summary:**
+   * Assign a severity and write a team summary on HackerOne for the reports
+     chosen in the `vulnerabilities.json`.
+   * Run `git node security --sync` to update severity and summary in
+     `vulnerabilities.json`.
+
+4. **Requesting CVEs:**
+   * Request CVEs for the reports with `git node security --request-cve`.
+   * Make sure to have a green CI before running it.
+
+5. **Choosing or Updating Release Date:**
+   * Use `git node security --update-date=YYYY/MM/DD` to choose or update the
+     release date.
+   * This allows flexibility in postponing the release if needed.
+
+6. **Get release volunteers:**
+   * Get volunteers for the upcoming security release on the affected release
+     lines.
+
+7. **Preparing Pre and Post Release Blog Post:**
+   * Create a pre-release blog post using `git node security --pre-release`.
+   * Create a post-release blog post using `git node security --post-release`.
 
 ## Announcement (one week in advance of the planned release)
 
-* [ ] Check that all vulnerabilities are ready for release integration:
-  * PRs against all affected release lines or cherry-pick clean
-  * PRs with breaking changes have a
-    [--security-revert](#Adding-a-security-revert-option) option if possible.
-  * Approved
-  * (optional) Approved by the reporter
-    * Build and send the binary to the reporter according to its architecture
-      and ask for a review. This step is important to avoid insufficient fixes
-      between Security Releases.
-  * Pass `make test`
-  * Have CVEs
-    * Use the "summary" feature in HackerOne to create a description for the
-      CVE and the post release announcement.
-      Example [2038134](https://hackerone.com/bugs?subject=nodejs\&report_id=2038134)
-    * Make sure that dependent libraries have CVEs for their issues. We should
-      only create CVEs for vulnerabilities in Node.js itself. This is to avoid
-      having duplicate CVEs for the same vulnerability.
-  * Described in the pre/post announcements
-
-* [ ] Pre-release announcement to nodejs.org blog: _**LINK TO BLOG**_
-  (Re-PR the pre-approved branch from nodejs-private/nodejs.org-private to
-  nodejs/nodejs.org)
-
-  If the security release will only contain an OpenSSL update consider
-  adding the following to the pre-release announcement:
-
-  ```text
-  Since this security release will only include updates for OpenSSL, if you're using
-  a Node.js version which is part of a distribution which uses a system
-  installed OpenSSL, this Node.js security update might not concern you. You may
-  instead need to update your system OpenSSL libraries, please check the
-  security announcements for the distribution.
-  ```
-
-* [ ] Pre-release announcement [email][]: _**LINK TO EMAIL**_
-  * Subject: `Node.js security updates for all active release lines, Month Year`
-  * Body:
-  ```text
-  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
-  For more information see: https://nodejs.org/en/blog/vulnerability/month-year-security-releases/
-  ```
-  (Get access from existing manager: Matteo Collina, Rodd Vagg, Michael Dawson,
-  Bryan English)
-
-* [ ] CC `oss-security@lists.openwall.com` on pre-release
-
-The google groups UI does not support adding a CC, until we figure
-out a better way, forward the email you receive to
-`oss-security@lists.openwall.com` as a CC.
-
-* [ ] Post in the [nodejs-social channel][]
-  in the OpenJS slack asking for amplification of the blog post.
-
-  ```text
-  Security release pre-alert:
-
-  We will release new versions of <add versions> release lines on or shortly
-  after Day Month Date, Year in order to address:
-
-  - # high severity issues
-  - # moderate severity issues
-
-  https://nodejs.org/en/blog/vulnerability/month-year-security-releases/
-  ```
-
-  We specifically ask that collaborators other than the releasers and security
-  steward working on the security release do not tweet or publicise the release
-  until the tweet from the Node.js twitter handle goes out. We have often
-  seen tweets sent out before the release and associated announcements are
-  complete which may confuse those waiting for the release and also takes
-  away from the work the releasers have put into shipping the releases.
-
-* [ ] Request releaser(s) to start integrating the PRs to be released.
-
-* [ ] Notify [docker-node][] of upcoming security release date: _**LINK**_
-  ```text
-  Heads up of Node.js security releases Day Month Year
-
-  As per the Node.js security release process this is the FYI that there is going to be a security release Day Month Year
-  ```
-
-* [ ] Notify build-wg of upcoming security release date by opening an issue
-  in [nodejs/build][] to request WG members are available to fix any CI issues.
-  ```text
-  Heads up of Node.js security releases Day Month Year
-
-  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.
-  ```
+1. **Publish Pre-Release Blog Post:**
+   * Publish the pre-release blog post on the `nodejs/nodejs.org` repository.
+
+2. **Send Pre-Release Accouncement:**
+   * Notify the community about the upcoming security release:
+     * `git node security --notify-pre-release`
+     * (Not supported yet)[Google Groups](https://groups.google.com/g/nodejs-sec)
+       * Email: notify <oss-security@lists.openwall.com>
+     * (Not supported yet)[Twitter](https://twitter.com/nodejs)
+     * [docker-node](https://github.com/nodejs/docker-node/issues)
+     * [build-wg](https://github.com/nodejs/build/issues)
+       We specifically ask that collaborators other than the releasers and security
+       steward working on the security release do not tweet or publicise the release
+       until the tweet from the Node.js twitter handle goes out. We have often
+       seen tweets sent out before the release and associated announcements are
+       complete which may confuse those waiting for the release and also takes
+       away from the work the releasers have put into shipping the releases.
+
+If the security release will only contain an OpenSSL update consider
+adding the following to the pre-release announcement:
+
+```text
+Since this security release will only include updates for OpenSSL, if you're using
+a Node.js version which is part of a distribution which uses a system
+installed OpenSSL, this Node.js security update might not concern you. You may
+instead need to update your system OpenSSL libraries, please check the
+security announcements for the distribution.
+```
 
 ## Release day
 
-* [ ] [Lock CI](https://github.com/nodejs/build/blob/HEAD/doc/jenkins-guide.md#before-the-release)
-
-* [ ] The releaser(s) run the release process to completion.
-
-* [ ] [Unlock CI](https://github.com/nodejs/build/blob/HEAD/doc/jenkins-guide.md#after-the-release)
-
-* [ ] Post-release announcement to Nodejs.org blog: _**LINK TO BLOG POST**_
-  * (Re-PR the pre-approved branch from nodejs-private/nodejs.org-private to
-    nodejs/nodejs.org)
-
-* [ ] Post-release announcement in reply [email][]: _**LINK TO EMAIL**_
-  * CC: `oss-security@lists.openwall.com`
-  * Subject: `Node.js security updates for all active release lines, Month Year`
-  * Body:
-  ```text
-  The Node.js project has now released new versions of all supported release lines.
-  For more information see: https://nodejs.org/en/blog/vulnerability/month-year-security-releases/
-  ```
-
-* [ ] Post in the [nodejs-social channel][]
-  in the OpenJS slack asking for amplification of the blog post.
-  ```text
-  Security release:
-
-  New security releases are now available for versions <add versions> of Node.js.
-
-  https://nodejs.org/en/blog/vulnerability/month-year-security-releases/
-  ```
-
-* [ ] Comment in [docker-node][] issue that release is ready for integration.
-  The docker-node team will build and release docker image updates.
-
-* [ ] For every H1 report resolved:
-  * Close as Resolved
-  * Request Disclosure
-  * Request publication of [H1 CVE requests][]
-    * (Check that the "Version Fixed" field in the CVE is correct, and provide
-      links to the release blogs in the "Public Reference" section)
-  * In case the reporter doesn't accept the disclosure follow this process:
-    * Remove the original report reference within the reference text box and
-      insert the public URL you would like to be attached to this CVE.
-    * Then uncheck the Public Disclosure on HackerOne box at the bottom of the
-      page.
-      ![screenshot of HackerOne CVE form](https://github.com/nodejs/node/assets/26234614/e22e4f33-7948-4dd2-952e-2f9166f5568d)
-
-* [ ] PR machine-readable JSON descriptions of the vulnerabilities to the
-  [core](https://github.com/nodejs/security-wg/tree/HEAD/vuln/core)
-  vulnerability DB. _**LINK TO PR**_
-  * For each vulnerability add a `#.json` file, one can copy an existing
-    [json](https://github.com/nodejs/security-wg/blob/0d82062d917cb9ddab88f910559469b2b13812bf/vuln/core/78.json)
-    file, and increment the latest created file number and use that as the name
-    of the new file to be added. For example, `79.json`.
-
-* [ ] Close this issue
-
-* [ ] Make sure the PRs for the vulnerabilities are closed.
-
-* [ ] PR in that you stewarded the release in
-  [Security release stewards](https://github.com/nodejs/node/blob/HEAD/doc/contributing/security-release-process.md#security-release-stewards).
-  If necessary add the next rotation of the steward rotation.
+1. **Lock down the CI:**
+   * Lock down the CI to prevent public access to the CI machines, ping a member of `@nodejs/jenkins-admins`.
+
+2. **Release:**
+   * Make sure the CI on all release proposals is green (test-V8, CITGM, etc).
+   * Follow the release process documented [here](https://github.com/nodejs/node/blob/main/doc/contributing/releases.md)
+
+3. **Unlock the CI:**
+   * Unlock the CI to allow public access to the CI machines, ping a member of `@nodejs/jenkins-admins`.
+
+4. **Publish Post-Release Blog Post:**
+   * Publish the post-release blog post on the `nodejs/nodejs.org` repository.
+
+5. **Notify the community:**
+   * Notify the community about the upcoming security release:
+     * Slack: `#nodejs-social`
+     * [docker-node](https://github.com/nodejs/docker-node/issues)
+     * [build-wg](https://github.com/nodejs/build/issues)
+     * Email: notify <oss-security@lists.openwall.com>
+
+## Post-Release
+
+1. **Merge the Next Security Release PR:**
+   * This involves moving the `vulnerabilities.json` file from
+     `security-release/next-security-release` to the `security-release/YYYY-MM-DD`
+     folder and merging the PR.
+
+2. **Cleanup:**
+   * Close PRs and backports.
+   * Close any pending PRs related to the security release.
+   * Close HackerOne reports:
+     * Close Resolved
+     * Request Disclosure
+     * Request publication of H1 CVE requests
+     * In case the reporter doesn't accept the disclosure follow this process:
+       Remove the original report reference within the reference text box and
+       insert the public URL you would like to be attached to this CVE.
+       Then uncheck the Public Disclosure on HackerOne box at the bottom of the
+       page.
+       ![screenshot of HackerOne CVE form](https://github.com/nodejs/node/assets/26234614/e22e4f33-7948-4dd2-952e-2f9166f5568d)
+   * PR machine-readable JSON descriptions of the vulnerabilities to the [core](https://github.com/nodejs/security-wg/tree/HEAD/vuln/core)
+     vulnerability DB.
+   * 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)
 
 ## Adding a security revert option
 
@@ -298,8 +225,4 @@ The steps to correct CVE information are:
 * Include all the details that need updating within the form
 * Submit the request
 
-[H1 CVE requests]: https://hackerone.com/nodejs/cve_requests
-[docker-node]: https://github.com/nodejs/docker-node/issues
-[email]: https://groups.google.com/forum/#!forum/nodejs-sec
-[nodejs-social channel]: https://openjs-foundation.slack.com/archives/C0142A39BNE
-[nodejs/build]: https://github.com/nodejs/build/issues
+[security-release]: https://github.com/nodejs-private/security-release