Node.js Security WG Initiatives 2023

[RafaelGSS]

Hey!

Since May 2022 the Security WG was reactivated and the team took the lead in 4 initiatives:

1. Node.js Dependency Vulnerability Workflow (Done)
2. Node.js Threat Model (Done)
3. Node.js Security Best Practices (Done)
4. Permission System (Work-in-progress)

First of all, thanks to everyone that helped on that journey, brilliant work.

As I mentioned on #843, it's time to think about future initiatives to improve the Node.js security ecosystem. So, I'd like to use this issue as a brainstorming thread to share some ideas. Ideally, share the problem and a potential solution, but, if you don't have a clear solution, don't worry, share it anyway.

This thread will be reviewed and discussed through the Node.js Security WG meetings (feel free to join).

@nodejs/security-wg

[RafaelGSS]

I can start:

Action to update our dependencies easily and fast (#828).

The issue was already created and @facutuesca is working on it. However, it's not officially a Security WG initiative yet. This will solve cases like the zlib update (nodejs/node#45387) that took a few weeks to be merged.

Flag to emit a warning when vulnerable

I was thinking of a flag (can be even without the flag) that checks if the current version is vulnerable. For instance, let's say the latest Security Release fixed a vulnerability on all active release lines (v14, v16, v18, v19). However, the v14 only applies to Windows (this is not true btw), which means, if you run Node.js v14.21.0 you shouldn't be affected by any known vulnerability, therefore, you shouldn't see the warning Your version is vulnerable to CVE-X,Y,Z.

$ node --experimental-security-scan index.js
(node:1) SecurityWarning: your Node.js version is vulnerable to CVE-XXXXX and CVE-YYYYYY.
Update to ensure your system stability (nvm install v18). 

Enforce communication with Node.js dependencies

Nowadays, when we get notified of an upcoming security release in any of our dependencies (OpenSSL for instance), we have the following workflow:

1. See the vulnerability level -- If critical/high prepare a Security Release asap
2. Wait for it to land
3. Assess if the vulnerability affects Node.js
   3.1) Share this assessment in our blog
4. Start the process of updating the dependency

However, our security release process is a tough task, it requires at least 2 weeks in advance to plan and make it work -- besides the fact, you need more than 3 releasers to help in this process.

I'm not quite sure if my suggestion is feasible, but I'd like to have a different communication with our dependency maintainers, mainly to get notified about the patch earlier. This way we can assess if the vulnerability affects Node.js or not.
For instance, OpenSSL notifies everyone of an upcoming security release, and then they send us a mail (they can even have access to the nodejs-private) sharing which function/behaviour is being affected by this vuln and then we assess it earlier. This way, we don't waste time preparing a Node.js security release without need.

By the way, I'd like to hear @nodejs/releasers thoughts on this too.

Security Status Page

This is a pretty similar approach to the second suggestion (Flag to emit a warning when vulnerable). I was thinking of something like https://status.github.com but security-wise. For instance, one can search their version and then see if that's vulnerable to that particular environment or not.

This is also valuable when performing a security release. Nowadays, we create a security release blog post https://nodejs.org/en/blog/vulnerability/november-2022-security-releases/ and update it when the time comes. However, I really doubt someone stays on that page or goes to it every time they need an update.

This page can serve as a status of the Security Release.

[mhdawson]

Two suggestions which I think @BethGriggs has been thinking about:

• Explore using SigStore to sign our releases
• Figure out how we stand in terms of key supply chain standards/frameworks.

[mhdawson]

And another one

Explore how the projects stands on the OSSF Scorecard

[mhdawson]

And one more that's been discussed in the past

Look at Fuzzing

[mhdawson]

I will also comment that I think Action to update our dependencies easily and fast (https://github.com/nodejs/security-wg/issues/828). is one of the top priorities and return on investment in my opinion.

[BethGriggs]

• Explore using SigStore to sign our releases

@lukehinds and I have recently got together to explore using SigStore to sign Node.js releases (first proposed a long while back in nodejs/Release#642). For now we're exploring how/where it would fit into the release process and how the value could be surfaced. It hasn't reached a proposal state just yet - but I wanted to share that there are already thoughts/discussions on that topic. For 2023, I'm sure something should happen in that space.

• Figure out how we stand in terms of key supply chain standards/frameworks.

The two that have been discussed are NIST SSDF and SLSA. We had a tentative plan to do an 'audit' of sorts where we can assess where the Node.js project is currently to then create actions to fulfil the not yet covered requirements. Early discussions were with @richardlau as it will likely involve a lot of build-related actions and context, and @sxa (who is doing similar work for another open source project). nodejs/build#3043 (comment) and SBOMs are likely topics to be explored as part of that work.

Just wanted to share that for those two topics there are discussions/work in flight.

[mhdawson]

@BethGriggs thanks for the info and great to have you confirm you are already pushing those two forward.

[mhdawson]

Adding to the brainstorm

• better versioning, mangement of tools need to build/update dependencies.

[RafaelGSS]

Update from #847

Action to update our dependencies easily and fast (#828).

It seems to have a positive consensus on this task.

Flag to emit a warning when vulnerable

• That's a useful task
• However, the concern of having to do a remote call to perform this check can cause some disagreements
• We thought of two approaches to workaround it:
  • Using an explicit flag, so users opt-in for the remote call check
  • Integrate that check on package managers (npm, yarn), since they already perform that remote call when installing a package

Enforce communication with Node.js dependencies

• That's doable and would be helpful, however, we're not quite sure about how feasible is it.

Security Status Page

We've agreed on this would require much work for a little improvement in the end. Therefore, it was removed.

Explore using SigStore to sign our releases

• That seems the good initiative
• However, it's not clear what it will solve and how the team can help
• @BethGriggs would you mind joining our next call to discuss and elaborate on it? If the time doesn't work for you, we can try to do it async

Figure out how we stand in terms of key supply chain standards/frameworks

• It's not clear what problem it will solve
• We leave that open for a better discussion in the next meeting

Explore how the projects stand on the OSSF Scorecard

• Agreement on that could be a good task

Look at Fuzzing

• That's a doable task
• We need to understand how useful it would be. We don't want to have another CI that nobody looks at it
• However, it will probably be a lower priority and be skipped in favor of other tasks

Better versioning and management of tools need to build/update dependencies

• @mhdawson will expand the description
• It seems a good task and in some points related to the OSSF Scorecard
• [MD expanded description] For each of dependencies look at the tools/sub-dependencies that are needed in order to build/update the dependency. For example some of the depenencies that generate WASM need wasi-sdk. For each tool/sub-dependency
  • document how we can identify and get the exact versions used for a particular Node.js release
  • review if we are pulling from an official/trusted source
  • review if we should store/keep our own copies or whether we can trust that the existing source to always be available
  • Identify any concerns or things that we should improve with respect to the above.

[BethGriggs]

@BethGriggs would you mind joining our next call to discuss and elaborate on it? If the time doesn't work for you, we can try to do it async

The next session unfortunately clashes with a conference for me. I may be able to make the following session (if it happens, being so close to the holidays). But, in the meantime, I'll try and summarise the discussions we've had so far and share.

[mhdawson]

@RafaelGSS this is the issue I mentioned related to Flag to emit a warning when vulnerable - nodejs/node#44942. Worth reviewing as a number of the same concerns/implementation challenges that were raised for the version checker may apply to emiting a warning when vulnerable.

[RafaelGSS]

That's more related to Security WG, but it may apply here too:

$ git node release --security (this can save a lot of time for security releases)