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.

[RafaelGSS]

Update: nodejs/node-core-utils#665

[RafaelGSS]

The last security release was created using the nodejs/node-core-utils#665 automation. It's missing two features:

• Support public PRs
• Support multiple commits with rebase

[RafaelGSS]

Since the OSSF Funding was approved for this work, I'll summarize the work in progress, and the remaining steps to this action, so whoever takes this task will be able to help me in this journey.

First of all, there are 3 fronts in this work:

1. Security Release Stewards automation
2. (Security) Release proposal automation
3. Automating release promotion

All those can be delivered in parallel, however, I recommend working on the last step (3. Automating release promotion) in the end.

Security Release Stewards automation

This is a work in progress and the first pull request created was:

• feat: create security release command node-core-utils#715

Generally speaking, there are 4 major steps for a security release steward:

1. Create the GitHub issue and list all the HackerOne reports being addressed by that release
2. Prepare the announcement (one week prior to the release)
   1. Request CVEs for all reports
   2. Create a security release announcement in nodejs.org. This post should contain which active release lines are affected and the severity scores.
   3. Announce it on twitter (ping #nodejs-social on OpenJS Foundation slack)
   4. Announce it via nodejs-sec email
   5. Notify affected teams through github issues: nodejs/build and nodejs/docker-node
3. Integration
4. Ask to releasers to start integrating their proposals (overlaps with front 2: (Security) Release proposal automation)
5. Lock CI
6. Pos Release
7. Unlock CI
8. Create a pos release announcement
   1. Publish an update to the security release blog post including the CVEs and details
   2. Close issues created (nodejs/build, nodejs/docker-node)
   3. Announce it on twitter
   4. Announce it via nodejs-sec email
   5. Close HackerOne reports as solved

Furthermore in https://github.com/nodejs/node/blob/main/doc/contributing/security-release-process.md.

The pull request mentioned addresses only the first step. We still need to work on the next ones.

Security Release proposal automation

This is a work in progress and the first pull request created was:

• lib: support security prepare node-core-utils#665

node-core-utils already provides an API to create proposals, but it's not 100% tested and it wasn't working well with security releases. See also:

• fix: enforce markdown when generating changelog node-core-utils#711
• fix: update changelog list when preparing release node-core-utils#712

The pull request merged has some limitations that need to be worked on:

• Add session to security releases
• Support multiple commits

More information can be found in the PR itself

Automating release promotion

Currently, we follow the step 10 until step 15 and all the releases are signed by the releaser local machine.

We're investigating other approaches like SigStore and SLSA, so might be worth it looking to the following issues:

• Node.js core SLSA.dev Review #876
• Consider endorsing/using Sigstore Release#642

That said, this work is about promoting and signing releases remotely in a Node.js specific machine, so reducing the work by the releasers + endorsing security practices since all the next releases will be signed by a unique trust machine. This work will need to align with @nodejs/releasers and @nodejs/build team.

[github-actions]

This issue has been inactive for 90 days. It will be closed in 14 days unless there is further activity or the stale label is taken off.