Node.js Doubles Security Releases with Newly Automated Process, Re-Evaluates Unsupported Experimental Features

If it seems like Node.js has been pushing out more security releases lately, it’s because they have—thanks to a newly automated process that has doubled the number of security releases in recent months. In their August 2024 security progress report, the Node.js security team detailed how automation has significantly streamlined their release process, allowing them to issue updates more frequently and efficiently.

“Only those who have been involved in a security release process know how hard it is (time-consuming, effort),” Node.js TSC member and security steward Rafael Gonzaga said.

“We've been working hard to automate most (if not all) of the process and the new security release process is live.”

The Node.js TSC is responsible for managing and responding to security reports against Node.js itself. They currently have a half a dozen security stewards in place who take ownership for coordinating the security releases. The stewards are nominated and approved through the regular TSC consensus process. Node.js also has a bug bounty program through the HackerOne platform.

In the past two months, Node.js released one security update and two additional updates sponsored by OpenSSF Alpha Omega (versions 22.5.0 and 22.3.0). Node.js has increased the frequency of security releases—issuing three in the past four months, compared to just five per year before collaborating with Alpha Omega. This automation is streamlining updates, ensuring the community receives security fixes faster.

Node.js Security Team Is Working with Next 10 Group to Re-evaluate Stale Experimental Features#

Alongside these improvements, the security team is also re-evaluating unsupported experimental features in collaboration with Next 10 to ensure a more secure codebase. Next 10 is a team that works on the strategic directions for the next 10 years of Node.js.

Gonzaga opened an issue to discuss the group’s policies regarding experimental features where there is no longer an active champion or creator overseeing them. These are projects that have remained inactive for a long period of time and are not receiving regular maintenance.

He cited a recent example where they dropped the --experimental-policy feature after receiving reports about it, which were difficult to assess due to no documentation defining its boundaries and security expectations.

There are 197 experimental APIs in nodejs/node/docs/api/**. Gonzaga proposed the group examine each inactive experimental feature to re-evaluate the benefits and decide whether to remove them entirely or delegate maintenance to a team.

“This approach will help us set clear expectations, assess and review vulnerabilities, and ensure better maintenance of our experimental features,” he said.

Other participants in the discussion suggested the group also consider where these features stand in terms of progress towards stability, field adoption, potential use cases, and user feedback.

“As I've mentioned many times before we have a more general problem with experimental features in terms of that we officially say that experimental features may change or be removed while in practice we don't want to do that due to breaking the ecosystem," TSC member Robert Nagy said.

After discussing a few specific features, the group is moving towards creating separate issues to debate each topic instead, as many of the features are driven by different groups of people.

This initiative to re-evaluate experimental features will help keep the project accountable for what is included, even when the original champion has moved on.

Check out Node.js’ August Security Report for more details on the team’s progress this month and follow the Node.js category on the OpenJS blog for future updates.