Experimental Features - Security expectations

[RafaelGSS]

Hello all!

We have had private discussions about handling valid vulnerabilities on experimental features. The TSC would be the best group to decide which point of view we look at for those vulnerability reports.

IMO even being experimental, any feature should be secure when it lands. Therefore, any vulnerability found should be reported and accepted at HackerOne. In this way, we can enforce a collaborative design by awarding security researchers that invest their time when a feature is still experimental and, thus, we guarantee a stable feature when the time comes.

I know @jasnell and others have different opinions, so would be great to hear your thoughts.

Once we have a decision, we probably need to document it properly (likely on nodejs/security-wg#799).

[Trott]

Once we have a decision, we probably need to document it properly (likely on nodejs/security-wg#799).

The Security WG is (or at least was at one time) focused on ecosystem security. It was never chartered to do a whole lot with Node.js core security. But perhaps that has changed? Regardless, I think the place to document the decision here (whether that would be instead of or in addition to the security-wg repo) would be https://github.com/nodejs/node/blob/main/SECURITY.md and/or https://hackerone.com/nodejs?type=team.

[Trott]

@nodejs/tsc

[jasnell]

In general, experimental features fall outside our support guarantees. They fall outside of semver rules. They are expected to have bugs and to not be used in production without taking on the associated risks yourself. Yes, the bugs should be fixed, but we should not feel obligated to treat them the same as non-experimental fully supported features.

[cjihrig]

IMO even being experimental, any feature should be secure when it lands. Therefore, any vulnerability found should be reported and accepted at HackerOne.

I agree with this (for supported versions of Node).

[aduh95]

IMO even being experimental, any feature should be secure when it lands. Therefore, any vulnerability found should be reported and accepted at HackerOne.

I agree with this (for supported versions of Node).

So if I may clarify, you agree with "any feature should be secure when it's made its way into a relaese", not when it lands on main, correct @cjihrig? Asking for a clarification because if we decide one way or another, it would have different implications for landing future experimental features.

[cjihrig]

We probably should not land code with known security vulnerabilities, but we definitely should not release code with known security vulnerabilities that can be exploited.

I thought this thread was more about how we respond to reported security vulnerabilities in supported releases. In that scenario, I think we should handle all security vulnerabilities through the same process, despite feature stability. If an experimental feature has known security issues then it should probably bake a little while longer before being included in a release.

[jasnell]

To be clear, I'm not saying that we should ignore or leave the issues unfixed. That would be silly. I'm saying that we shouldn't feel obligated to treat them the same way and care as vulnerabilities in supported features.

[Trott]

To be clear, I'm not saying that we should ignore or leave the issues unfixed. That would be silly. I'm saying that we shouldn't feel obligated to treat them the same way and care as vulnerabilities in supported features.

In other words: We should certainly fix the vulnerabilities, but we don't need to do it in the private repository and we don't need to issue a CVE. Do I understand your position correctly, @jasnell?

[jasnell]

Yes, that is correct

[Trott]

I am interested in what the @nodejs/security-triage folks think about this. @RafaelGSS and @jasnell have indicated their thoughts here. What about @danielleadams @mhdawson @vdeturckheim and @mcollina?

[targos]

I'm thinking there should be some middleground. For example, issue a CVE if the feature is enabled by default (without a specific flag to opt into it). The reason is that when the feature is not gated by a flag, your application may be using it without your knowledge through a third party dependency.

[GeoffreyBooth]

This relates to some of what we’re discussing in https://github.com/nodejs/node/discussions/45084. I think we need to clarify “experimental features” a bit. There are different levels (which maybe we should codify somewhere):

• An experimental feature merged on main but unreleased.
• An experimental feature enabled only via build flag.
• An experimental feature that requires a command-line flag to enable.
• An experimental feature that prints a warning.
• An experimental feature where the only way you’d know it’s experimental is by reading the documentation.

Security exploits don’t care about experimental status. What matters, I think, is whether the vulnerability can be exploited by third-party code (either the app’s dependencies or from outside like via a network call) without the user having opted into the experimental feature. So this would mean that we can offer lesser security guarantees for experimental features that are gated behind build or command-line flags (or that are merged in but unreleased). Once an experimental feature is released and available by default, though, like fetch, I think it needs to be treated the same as any other part of Node. It’s providing a vulnerability to attackers, regardless of whether it’s experimental or not.

(Edit: jinx @targos 😄)

[mcollina]

We should never enable by default features with known security vulnerabilities according to our threat model. With the exception of security features (like policies, etc), this could be interpreted also to never land PRs with known security vulnerabilities. This is kind of implicit in the PR review process but we might want to spell it out.

Regarding things for which we issues CVE, I think anything that's shipped on a release and does not require a --experimental- flag is subject to our security policy.
We might want to document this and update the HackerOne page.

[RafaelGSS]

So, does the --experimental-x flag means the feature is subject to vulnerabilities? Well, for most of the features I can concur on that. However, we have some security features behind that flag, and basically, this statement says that nobody should use it, and clearly we won't have feedback.

If the feature goal is to increase the security of userland code and because it's behind the --experimental-x flag it will be subject to vulnerability, this will totally defeats the purpose of the feature