search

nodejs / security-wg

Node.js Ecosystem Security Working Group
MIT License
499 stars 121 forks source link

Automate security release process #860

Open RafaelGSS opened 1 year ago

RafaelGSS commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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

mcollina commented 1 year ago

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[bot] commented 1 year ago

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 commented 1 year ago

Update: https://github.com/nodejs/node-core-utils/pull/665

RafaelGSS commented 1 year ago

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

RafaelGSS commented 1 year ago

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:

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
    1. Ask to releasers to start integrating their proposals (overlaps with front 2: (Security) Release proposal automation)
    2. Lock CI
  4. Pos Release
    1. Unlock CI
    2. Create a pos release announcement
    3. Publish an update to the security release blog post including the CVEs and details
    4. Close issues created (nodejs/build, nodejs/docker-node)
    5. Announce it on twitter
    6. Announce it via nodejs-sec email
    7. 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:

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:

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

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:

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[bot] commented 1 year ago

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.

github-actions[bot] commented 9 months ago

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.

marco-ippolito commented 9 months ago

Brief update on the security release automation process:

marco-ippolito commented 8 months ago

Brief update on the security release automation process:

UPDATE: Hackerone has released new APIs to automate CVE handling. I've created a PR to automatically request CVEs: https://github.com/nodejs/node-core-utils/pull/777 @mhdawson has sent a ticket to hackerone to ask for a playground for those APIs since we cannot test in production. We will test the cve creation in the next security release.

mhdawson commented 8 months ago

@marco-ippolito did you get the email from H1? they had provided a link. Maybe you are not on CC for the ticket even though I added you as a CC. will forward the email.

marco-ippolito commented 8 months ago

@marco-ippolito did you get the email from H1? they had provided a link. Maybe you are not on CC for the ticket even though I added you as a CC. will forward the email.

Got it thanks!

marco-ippolito commented 7 months ago

Update on the security release process automation.

I'm still waiting for a response from HackerOne since it's not possible to request CVE in the "sandbox" playground application, so might have to test it on the field 👿

github-actions[bot] commented 2 months ago

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.