In June, we saw all of our Node.js security metrics trending in the right direction. Closed reports were up, average first response time was down (again), and much more. Our Threat Model is now being used regularly to help assess issues. And we are getting comments on our Security Model, which is the kind of interaction that makes processes robust. We’re not claiming victory, but this feels like progress.
As always, we want to say thank you to OpenSSF and Project Alpha Omega for their support. You can read more details about our partnership here: Security Support Role 2023.
Fixing and Triaging Security Issues
The Node.js team closed 17 reports in June which is a big increase from the 2 completed in May. We don’t expect the number of reports to increase linearly, but this still qualifies as a good month for improving Node.js security issues.
Also, Node.js team’s average first response time in June was 3 hours, compared to 8 in May. Remember our goal is average first response within 48 hours, so this is excellent. We’d like to extend special thanks to Tobias, Bradley and Rafael for their help as volunteer triagers!
A lot of effort was made to include all the fixes on time for the Node.js security release that went out on June 20, 2023. Last year, security releases came out about once per quarter, which was not frequent enough. We are looking to increase the frequency this year.
Support for Security Releases
Security Release coordination continues to improve. All the processes described by the security release process – multiple steps for planning, announcement one week in advance, and release day – were completed.
One big improvement is automation. For each security release, there used to be 26 steps and then 12 steps for the release itself. But with the OpenSSF investment, we have been able to dedicate time to automate, establish new processes, and streamline the workflow. Each version required all those steps (v20.3.1, v18.16.1, and v16.20.1).
The most recent Security Release included updates of two Node.js dependencies: OpenSSL and c-ares. All the releases were sponsored by OpenSSF.
And there was one regular release of Node.js v20.3.0!
Node.js Security Working Group Initiatives
The Security Working Group is making progress on the 4 main initiatives for the Security Working Group Initiatives for 2023: Permission Model, Automate update dependencies, Assessment against best practices, and Automate Security release process.
|Permission Model – 2 Phase
|Automate update dependencies
|Assessment against best practices
|Automate Security release process
For the Permission Model, 5 security fixes for CVEs were completed. Regular fixes and pull requests were also addressed.
The Security WG is actively looking for more feedback. If you are interested in helping to define the initiatives, please participate!
Automated Update Dependencies
The initiative has been completed, it was just missing backports. It is now ready to be merged! 🎉
Assessment Against Best Practices
The Security WG is continuously looking at best practices and doing improvement on each Security WG call. One area of effort is CII-Best-Practices for Node.js Projects. Node.js looked at this early, 7 years ago, which means we were forward looking, but it needs to be updated.
Automate Security Release process
A PR has been created to automate the release proposal for security releases. The Security Release proposals were created using this automation
Connecting with us – Recent Speaking Engagements
- 5 Ways You Could Have Hacked Node.js
- TheDevConf Innovation (June 15th)
- Improving the Security of a Large Open Source Project One Step at a Time
- Open Source Summit EU
- NodeBR – Experience (July 22th)
- Node.js Collab Summit
- Blog post covers one of the Security Working Group initiatives: “Why you should pin your Github actions”
- Alpha-Omega Public Meeting (July 6th)
- Good discussion around assessing experimental features. Should experimental features be assessed in the same way as stable features? Currently under consideration.
Improving Security Processes
There is a new PR now to help create security issues. It automates GitHub issue creation. It should eventually manage all states of a security release. The PR includes a new command CREATE and there will be other PRs to manage steps beyond CREATE, such as requesting CVEs, creating issues, sending emails and more.
Are you interested in getting involved? The new Permission Model is still experimental, which makes it the right time for you to try it. Be sure to join us for this month’s meetings: https://github.com/nodejs/security-wg.