Automate security release process

[RafaelGSS]

This is one of the initiatives we agree on for 2023. We all know how hard and time-consuming is to perform a security release. However, some of the 42 steps can be easily handled by automation. This initiative aims to improve this process using the well-known CLI (git node).

I'm tempted to have a git node release --security that starts all the processes described in https://github.com/nodejs/node/blob/main/doc/contributing/security-release-process.md#planning.

cc: @nodejs/security-wg @nodejs/releasers

[richardlau]

@RafaelGSS There's already a git node release --security, which is intended for use by releasers when preparing security releases (it automatically adds "This is a security release." to the changelog entry). I would keep this existing command for releasers and have a separate command for the release steward's steps automation.

[BethGriggs]

@RafaelGSS There's already a git node release --security, which is intended for use by releasers when preparing security releases (it automatically adds "This is a security release." to the changelog entry).

In the context of that tool and this initiative, it may be worth exploring extending it to encourage a standard structure/template for the security release 'Notable changes' entries too. Example:

### Notable Changes

* **CVE-2021-3672/CVE-2021-22931**: Improper handling of untypical characters in domain names (High)
  * Node.js was vulnerable to Remote Code Execution, XSS, application crashes due to missing input validation of hostnames returned by Domain Name Servers in the Node.js DNS library which can lead to the output of wrong hostnames (leading to Domain Hijacking) and injection vulnerabilities in applications using the library. You can read more about it at <https://nvd.nist.gov/vuln/detail/CVE-2021-22931>.
...

At times we have just referenced the post-release blog post, but it's probably useful to always include details of the CVEs in the changelogs.

I am guessing it will not be easy to automate the population of all of the CVE details (as I don't think they are available in a structured format at the point of preparing the release*). But, I still think it'd be useful to have a default template/structure placeholder agreed so our security release changelogs can start to detail the vulnerabilities in a consistent format.

Structure to be discussed/agreed, but even something like:

### Notable Changes

The following CVEs are fixed in this release:

* **<CVE-ID>**: <CVE-TITLE> (<CVE-SEVERITY>)
  * <CVE-DESCRIPTION>
...

*At a minimum, we should be able to determine and populate the unique CVE IDs from the CVE-ID: metadata on the commits in the proposal.

[mcollina]

The most error prone step is generating CVEs with all the correct metadata associated. I think we should change how we do it, avoid filling the details twice.

Ideally, we should have a process that allows those to be reviewed in a PR, and not with a one-man step.

[mhdawson]

@mcollina I wonder if there as an API for H1. If so maybe that could be used to automated based on a PR.

[mcollina]

I couldn't find it. Can we ask them to add one for us? The need to automate this step might get us back to issuing our CVEs instead of relying on H1 to do it for us.

[github-actions]

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.