Node.js Security Progress Report – First Response Time Down to 8 Hours, New Security Release Announced

Last month, we reported that the first response time in April was down to 18 hours. For May, it dropped again, down to 8 hours. Our established goal is a 48-hour response time, making an 8 hour response time excellent. Real-world response time will likely fluctuate up and down some moving forward as we work through improving our processes including our new Permission Model and automation of dependencies and build processes. 

Beyond that, 5 reports were created in April and 2 were closed from May. In April, 6 hackers participated. This type of outside participation is extremely encouraging, thank you for your contributions!

We completed the first initiative from 2023 for automating dependencies. This will go a long way to creating security sustainability and we’re  working hard on automating the security release process itself. 

Big thanks to OpenSSF and Project Alpha Omega for their continued support. Partnership details are outlined here: Security Support Role 2023.

Support for Security Releases

The next security release is scheduled for June 20, 2023, and we are actively working on multiple security fixes. OpenSSL Security Release 29/05 came out and will be integrated into this release and the c-ares security release. 14 reports affecting different active release lines came out in May. More information here.

Three regular releases came out (v20.1.0, v20.2.0 and v20.3.0) and we’ve been focusing on coordinating upcoming releases, making sure there is clear alignment with the Node.js team and releasers, and creating and backporting fixes.

What’s a backport? Many security fixes are for the most recent version since this is the focus of attention. The goal is to create backport pull requests for previous versions at the same time. So, if we fix something in Node.js 20, there are fixes available for older versions, like Node.js 16, when needed.

Node.js Security Working Group Initiatives

There was good discussion about supporting environment variables as part of the Permission Model. The idea is to know explicitly what resources an application is accessing when it runs.

The current proposal is to add variable names into an allowlist using the –allow-env flag as shown below. Any variables not included in the allowlist will be inaccessible through process.env.

Assessment against security best practices to make progress. We are actively monitoring undici, node, and security-wg repositories. And we are improving the OSSF Scorecard undici that helps in our assessment in comparison with best practices.

Node.js Security Sustainability

Check out all of our recent speaking engagements:

• The State of Node.js Security 2023
• Improving the Security of a Large Open Source Project One Step at a Time
• Node.js Security WG initiatives by Michael Dawson
  undefined

We’re meeting with the Google Open Source Security Team to discuss the Permission Model. They’ve participated in our recent Security WG sessions, and we believe this is a positive step forward in helping with security sustainability.

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