Node.js

Node.js Security Progress Report – Fewer Steps and More Releases


In July, we continued our regular work triaging and fixing Node.js security issues. We also welcomed a new contributor to the Node.js Security Working Group team, and increased the number of security releases, which improves security by making updates available more quickly. We have also continued to evaluate the Permission Model including adding a startup benchmark, adding support for V8 HeapSnapshot and Node.js reports, and cut down the number of steps it takes to create a security release.

In July, we continued our regular work triaging and fixing Node.js security issues. We also welcomed a new contributor to the Node.js Security Working Group team, and increased the number of security releases, which improves security by making updates available more quickly. We have also continued to evaluate the Permission Model including adding a startup benchmark, adding support for V8 HeapSnapshot and Node.js reports, and cut down the number of steps it takes to create a security release. Nice 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

We closed 8 reports in July with 7 developers participating. Our average first response time in July was 53 hours, compared to only 3 hours in June, but we don’t expect month-to-month to always improve. It’s easy when we receive a report from contributors about the Node.js codebase, because we can quickly assess whether the report is accurate or not, almost at-a-glance. But sometimes we get reports that require a long assessment discussion before triagging the report as valid. In other words, not all reports are created equal. This elongates the process.

We also had discussions around the Node.js policy mechanism. Policies are a security feature intended to allow guarantees about what code Node.js is able to load. Some incoming issues were actually not vulnerabilities. This means people are opening issues in part because our descriptions are not clear enough. We are looking to improve in this area.

Support for Security Releases

We have started to reduce the period between security releases. 2 security releases in in the past 2 months. By shipping security versions faster and more often, it means people will get more secure versions. 

For the most recent Security Release (released on Aug 9, 2023), all the processes described in the security release process were completed, including evaluating all Reports, requesting CVEs, and doing the pre- and post- Security Release announcements). The Security Release includes updates to OpenSSL. 

And, two new people were interested in joining the release team. This kind of real, direct participation is great news!

Node.js Security WG Initiatives

Check out the 2023 Security Initiatives here: https://github.com/nodejs/security-wg#current-initiatives

We are continuing to reevaluate the Permission Model. We want to better understand how useful the Permission Model is to end users. We are getting positive feedback so far. We have also done research comparing Permission Models for other runtimes and languages. We looked at Deno, Python, Ruby, and Java. The only Permission Model similar to Node.js is Deno.

Among other improvements to the Permission Model, we added a startup benchmark – nodejs/node#48905. It shows the impact on performance of the Permission Model when it starts being used. According to our benchmark tests, the overhead is low, which is excellent.

More Permission Model improvements include:

  • The Permission Model Tree can be visualized by the debug environment variable NODE_DEBUG_NATIVE=PERMISSION_MODEL
  • Fixed Permission Model usage when using Node.js REPL
  • Restricted all available resources (file system, worker, child_process, inspector) when the permission model is enabled

We also are continuing to assess our security processes against Best Practices and are looking for continuous improvement on every Security WG call. This project was formerly known as the Core Infrastructure Initiative (CII) Best Practices badge. and was originally developed under the CII. It is now part of the OpenSSF Best Practices Working Group (WG). The OpenSSF is a foundation of the Linux Foundation (LF). The project was formally renamed from “CII Best Practices badge” on 2021-12-24. We have completed the Entry Level for CII-Best-Practices. For the Silver Level, there is only one question remaining! We are aiming to get to the Gold level soon. nodejs/security-wg#953

The PR to automate the security release process for security releases has been merged! nodejs/node-core-utils#665 This further automates the release process, cutting it down from 26 steps to 20. Not all steps are created equal, and the reduced steps are some big ones that took extra time. This is a huge win on the release side. And a PR has been created to automate the next Security Release issue. It is not merged but it is ready. It was used with the most recent security release. It is an  “absolute significant productivity boost.”

https://github.com/nodejs/node/blob/main/doc/contributing/releases.md

Get Involved

Recent and Upcoming Speaking Engagements

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