Skip to main content
Category

Node.js Security

Node.js Security Progress Report – Security Release and Node.js 21

By Blog, Node.js, Node.js Security

Thank you to the continued support from the Alpha-Omega project at the OpenSSF Project, helping us make Node.js more secure and easier to build! 

October was busy due to the latest security release affecting Node.js 18 and Node.js 20. Usually, we lock in the Continuous Integration (CI) cycle at least 5 days before a  release. This time, however, due to the recent changes to the CITGM (Canary In The Gold Mine: a simple tool for pulling down an arbitrary module from npm and testing it using a specific version of the node runtime) and changes to the automation of the security release proposal, it was just 3 days.

Speedy!

And, a day after the security release, we put out Node.js 21. Main updates for Node.js 21:

  • V8 JavaScript engine updated to 11.8
  • Stable WebStreams which helps to process data in small sizes for applications
  • A new experimental flag to flip module defaults (–experimental-default-type) – Node.js has two module systems: CommonJS modules and ECMAScript modules. Node.js treats files with a .js extension by default as CommonJS modules. This can now more easily be flipped.
  • Many updates to test runner which allows users to run functional tests and export results

If you’d like to find out more about Node.js 21:

This means a transition from Node.js 20 to LTS. Node.js 21 is now our Current release.

Security Release

In October, Node.js addressed 4 CVEs within Node.js and 2 within its dependencies:

  • 2 High severity issues
  • 1 Medium severity issue
  • 1 Low severity issue in Node.js
  • Security updates for undici and nghttp2

The 20.x release line of Node.js was vulnerable to 2 high severity issues, 1 medium severity issue, and 1 low severity issue. The 18.x release line was vulnerable to 1 medium severity issue, and 1 low severity issue.

Users can always check their version’s vulnerability status by running:

$ npx is-my-node-vulnerable

Security initiatives and assessments

Recently, OpenSSL disclosed 3 security releases which were assessed by the Node.js team as non-critical patches. They were handled in regular releases.

Additionally, two pull requests were created to update Permission Model stability. The Permission Model has been moved to version 1.1 and Active Development. We’ve documented that some files can be read before V8 initialization, which implies before permission model initialization, too.

With the intention of improving the scorecard for different repositories under Node.js, we created 5 pull requests to pin Github Actions by commit-hash. We are evaluating how effective this approach is for non-libraries since it can cause some maintenance burdens for the maintainers. 

You can pin Github Actions by tag without having to manually (or through dependabot) update semver-minor and semver-patch releases. actions/checkout@v2 will always fetch the latest release of v2.

In October, we’ve added support to Ada and simdtuf to our dependency-vulnerability-scanner. And Node.js 21 was added to the cycle.

As a final update, we’ve identified that a previous security release might have broken the usage of the esm npm package. However, considering this package is now archived and the usage of monkey patching is not guaranteed by Node.js, it is unlikely a patch will be produced.

Interested in getting involved with Node.js security? We are actively looking for new contributors! Find out more about the Node.js Security Team here: https://github.com/nodejs/security-wg

Node.js Security Progress Report – Looking Into SBOM for Node.js

By Blog, Node.js, Node.js Security

September was a busy month with participation in 3 different events, regular work on security reports, and discussions around creating an SBOM for Node.js.

In September, we responded to 9 submitted reports (3 Triaged, 3 Closed as non-applicable, 3 Closed as informative) and the average first response time was 4 hours and 30 minutes, slightly faster than in August.

Work on Node.js security is thanks in part to the Open Source Security Foundation (OpenSSF) and the Project Alpha Omega. You can read more details about our partnership here: Security Support Role 2023.

Possible Software Bill of Materials (SBOM) for Node.js

We are now actively looking at ways to include a Software Bill of Materials (SBOM) for Node.js releases. In May 2021, the US government issued an Executive Order on Improving the Nation’s Cybersecurity which specifically advocates providing SBOMs for software products. 

From the executive summary:

“…the term ‘Software Bill of Materials’ or ‘SBOM’ means a formal record containing the details and supply chain relationships of various components used in building software.  Software developers and vendors often create products by assembling existing open source and commercial software components.  The SBOM enumerates these components in a product.  It is analogous to a list of ingredients on food packaging.”

However, exactly what the SBOM includes is debatable. Timing for implementation is not decided. The full internal Node.js discussion on adding an SBOM for Node.js is available here: https://github.com/nodejs/security-wg/issues/1115 

Node.js Security WG Initiatives

Creating Security Release issues is now automated. The new command manages all the states of a security release. It  includes CREATE. In the future, it will include requesting CVEs, creating issues, sending emails and more.

Node.js Security Sustainability

September was a month full of speaking engagements. We believe events like the ones listed below are an excellent opportunity to connect directly with the Node.js community and to get feedback and welcome outside contributors. We hope to meet you face-to-face in the near future!

  • “The State of Node.js Security”
    • Node.js Collab Summit, Bilbao, Spain, Sept 18th
  • “The Journey of Node.js Permission Model”
    • OpenSSF Day, Bilbao, Spain, Sept 18th
  • “Improving the security of a large open source project”
    • Open Source Summit EU, Bilbao, Spain, Sept 20th
  • “Node.js Project”
    • Grace Hopper Celebration Day, virtual, Sept 22th
  • “Improving the security of a large open source project”
    • OpenJS World, Shanghai, China, Sept 26th

Interested in getting involved with Node.js security? The new Permission Model is still experimental, which makes it the right time for you to try it. We are actively looking for new contributors. And, we’re super friendly! 🙂

Find out more about the Node.js Security Team here: https://github.com/nodejs/security-wg

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

By Blog, Node.js, Node.js Security

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

Node.js Security Progress Report – 17 Reports Closed

By Blog, Node.js, Node.js Security

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. 

InitiativeChampionStatusLinks
Permission Model – 2 Phase@RafaelGSSIn ProgressIssue #898
Automate update dependencies@marco-ippolitoDoneIssue #828
Assessment against best practices@fraxken/@ulisesGasconIn ProgressIssue #859
Automate Security release process@RafaelGSSIn ProgressIssue #860

Permission Model

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

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.

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

By Blog, Node.js, Node.js Security

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:

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

Node.js Security Progress Report – Automation, Automation and more Automation

By Blog, Node.js, Node.js Security

Last month, the Security Working Group initiatives focused on the Permission Model and Automated Update Dependencies. 

There were 10 security reports in April with more people participating than the previous month. Response time in April was 18 hours before the first response back from us, which is less than our goal of a 48 hour response time.

As always, thank you to OpenSSF and Project Alpha Omega for their continued support. The exact details of the partnership are outlined here in the Security Support Role 2023 document.

Automation Update Dependencies

In total, 11 dependency update automation were completed this month, which included undici, openssl, v8, npm and more. There are only 2 more automations to go.

As a reminder, the Security Working Group started investigating dependencies in Node.js in November last year. They identified automated updates, and which ones should be prioritized: https://github.com/nodejs/security-wg/issues/828. We can already see the benefits of this work by looking at the increased number of pull requests for dependency updates automatically submitted to the project. 

Security Release Automation

The Security Working Group is focusing on implementing automation for the key dependencies in the build. This makes the overall process easier and less prone to error, and it makes it possible in the future for different stewards to complete the process. 

There are currently 26 steps in doing a Node.js security release.If greater automation works, it will be a big step forward. Please expect more information on this topic soon!

Permission Model

There have been over 10 months of work on building a new Permission Model. To help clarify next steps and guide the discussion, a roadmap issue (#898) was created to discuss the future of the Permission Model. 

Are you interested in getting involved? The new Permission Model is still experimental, which makes it the right time for you to try it. Any bugs are considered vulnerabilities because they are security features. 

JavaScriptLandia Awards: Pathfinder for Security 

Last week at OpenJS World 2023, the OpenJS Foundation held their second annual JavaScriptLandia awards and recognized Rafael Gonzaga from Nearform. 

Rafael has made significant contributions to Node.js security and has received positive feedback on his efforts to improve the security ecosystem. His contributions to reports and blogs have generated great visibility from social media, and he has personally trained and brought engineers into the Node.js Security Working Group to build the community towards self sufficiency. 

Congratulations, Rafael!

Join Us!

Be sure to join us for this month’s meetings: https://github.com/nodejs/security-wg

Node.js Security Progress Report –  Permission Model Merged

By Blog, Node.js, Node.js Security

February included several major steps forward in improving Node.js security. We merged the Permission Model which we built over the past 8 months. This will make Node.js more secure by allowing the user to restrict machine resources, such as file system. More information will be provided on Node.js v19.9.0 release. We also merged the security support role, fixed and triaged issues and engaged with multiple working groups. Which means more resources and more clear processes for making Node.js secure.

As always, thank you to OpenSSF and Project Alpha Omega for their continued support.

Permission Model landed in the main branch

The Permission Model was merged into the main branch. There was over 8 months of work leading up to this point. This final month leading up to the merge required a lot of time and effort and discussion. To help clarify next steps and guide the discussion, a roadmap issue (#898) was created to discuss the future of the Permission Model. https://github.com/nodejs/security-wg/issues/898 

The Security Support Role 2023 was also merged last month. There are 6 focus areas that show the goals of this work.

  • Fix and Triage Security Issues
  • Support for Security Releases
  • Node.js Security WG Initiatives
  • Node.js Security Sustainability
  • Improving Security Processes
  • Ecosystem Adoption

More details can be found here: https://github.com/ossf/alpha-omega/blob/main/alpha/engagements/2023/node.js/security-support-role.md 

Node.js database automatic updates

We’ve improved the Node.js database to now automatically update. When there is a new CVE or vulnerability, the database will be updated and anyone has access to that information.

Working group progress

We participated directly with working groups, 9 sessions total. There was excellent attendance for the February Security Working Group meeting. This month, Microsoft joined us and expressed interest in helping with policy around Single Executable Applications.


Be sure to join us for this month’s meetings as well: https://github.com/nodejs/security-wg.

Node.js Security Progress Report – OpenSSF Grant Renewed for 2023, New Ecosystem Focus

By Blog, Node.js, Node.js Security

January was busy with HackerOne reports, vulnerability fixes for OpenSSL and Node.js and security updates due to the upcoming Node.js security release.

In 2022, we started receiving assistance from the Open Source Security Foundation (OpenSSF) Project Alpha-Omega grant to support more resources to help with Node.js security. The grant has been renewed at just under $300,000 for the calendar year. OpenJS Foundation works with NearForm to fulfill the grant goals. 

With so much accomplished last year, we look forward to further improving Node.js security in 2023. Thank you to OpenSSF for their continued support.

Fixing and Triaging 21 Issues

There were 5 new HackerOne reports in January along with 8 vulnerabilities to fix from OpenSSL, and 8 for Node.js due to the upcoming security release. The improved Threat Model is helping to assess priority.

New Node.js CVE Database

Security Working Group initiatives have been making progress. CVEs are now stored in a database that is accessible by all. CVEs had been stored in the Security Working Group repo, but the repo was not perfectly up-to-date. The Node.js database fixes this issue and can be used by vendors.

Google Open Source Security Team (GOSST) Participation

The Google Open Source Security Team (GOSST) participated in the January 19, 2023, Security Working Group meeting. GOSST contributes to OpenSSF Scorecards, and they brought a lot of helpful discussion topics. OpenSSF Scorecards are a cross-industry initiative to improve open source software security, with a focus on metrics, tooling, best practices, developer identity validation and vulnerability disclosures best practices. 

Expanded Ecosystem Focus

Ecosystem adoption is a key component to Node.js security. We are finalizing the Permission Model, and will be looking to increase participation on GitHub when it is finalized and ready for use. The end goal is a smooth process for installing a package with the correct tag.

Most recently, we reviewed and fixed a bug for Fastify that will be released with the Node.js security release. We also did fixes for Undici, an HTTP/1.1 client. 

Early Work on is-my-node-vulnerable

We created a package called is-my-node-vulnerable to make it easy to test your own implementation of Node.js. It helps ensure the security of your Node.js installation by checking for known vulnerabilities. It compares the version of Node.js you have installed (process.version) to the Node.js Security Database and alerts you if a vulnerability is found. So far, we are getting good feedback from the community. We are currently thinking about how to show to vendors and how to get more involvement. 

Join Us!

We had one Security Working Group meeting in December and three Technical Steering Committee meetings. https://github.com/nodejs/security-wg 

Node.js Security Progress Report – More Successful December Outcomes

By Blog, Node.js, Node.js Security

December was a busy month! We handled more reports and more fixes than ever. In fact, we spent most of our time working on fixes, which is exactly as it should be. We are also starting work on ecosystem issues, which will be an important improvement to Node.js security in 2023.

In 2022, we started receiving assistance from the Open Source Security Foundation (OpenSSF) Project Alpha-Omega grant to support more resources to help with Node.js security at the OpenJS Foundation. As always, we are very grateful for this support of open source software. 

We finished the year on a strong note – check out these tweets on @nodejs to see the progress made!

Fixing and triaging 9 issues

5 HackerOne reports were fixed or triaged, 2 previous reports had the fixes disclosed, and 2 ecosystem issues were handled with one having a fix approved and one fixed and released.

Starting new work on ecosystem issues

Ecosystem adoption is a key component to Node.js security. We are finishing the permission model, and will be looking to increase participation on GitHub when it is finalized and ready for use. The end goal is a smooth process for installing a package with the correct tag.

In December, we fixed 2 vulnerabilities for Fastify and one has already been disclosed: https://github.com/fastify/fastify/security/advisories/GHSA-3fjj-p79j-c9hh.

OpenSSL update 

OpenSSL announced a low vulnerability issue that affects OpenSSL 3.x users which means Node.js v18+. We evaluated the issue and disclosed our assessment. This vulnerability doesn’t affect Node.js and will be fixed in regular releases.

Node.js releases

There were 3 regular releases in December. We hope to have the next security release out by the end of January 2023. Stay tuned!

Join us!

We had one Security Working Group meeting in December and three Technical Steering Committee meetings. If you want to get involved, let us know!