Scores of vulnerability found in experimental features can be too high about security-wg HOT 9 OPEN

Note that the CVSS does not have an indicator of “how many users are affected”… by design.

It’s a failure of that scoring system.

from security-wg.

TL;DR: I brought up that discussion in the past and turns out that regardless of ~1% of Node.js users make real use of it, this vulnerability is still HIGH for the ones who use it. We have decided to assess experimental features in the same way we assess stable features. Although it may seem more pressing than it actually is, I believe that it is the safer and more appropriate approach.

from security-wg.

For reference, we have iterated over it in the past: nodejs/TSC#1299

from security-wg.

TL;DR: I brought up that discussion in the past and turns out that regardless of ~1% of Node.js users make real use of it, this vulnerability is still HIGH for the ones who use it. We have decided to assess experimental features in the same way we assess stable features. Although it may seem more pressing than it actually is, I believe that it is the safer and more appropriate approach.

I do agree, it's not easy to estimate the impact of a vulnerability, so we can only measure the severity

from security-wg.

I see, if we cannot do anything about the severity, I wonder if we could at least make assessments of the vulnerabilities more effortless for the users. For example, we can try to develop a template for the descriptions, and consistently begin the description with something like:

Only users who rely on --experimental-flag are affected by this vulnerability

Or, with an even stronger wording:

Users who do not currently rely on --experimental-flag are not affected by this vulnerability.

instead of placing the scope near the end of the description. Or applying [Stable] [Experimental] [Legacy] label to the title according to the stability index of the feature being affected. That could already go a long way. With the current model, for people scrolling through the summaries to understand whether how much the vulnerability matters for them, I suspect this would probably be the most valuable information, as most of our vulnerabilities happen in very specific situations that only affect a minority of the audience, and one just want to know whether this matters for them or not before they even dive into how the vulnerability works.

from security-wg.

For example, we can try to develop a template for the descriptions, and consistently begin the description with something like:

Well, we normally mention it in the security release notes, for instance:

"This vulnerability affects all users using the experimental permission model in active release lines: 20.x and 21.x."

Ref: https://nodejs.org/en/blog/vulnerability/february-2024-security-releases#path-traversal-by-monkey-patching-buffer-internals-cve-2024-21896---high

from security-wg.

Well, we normally mention it in the security release notes, for instance:

I think the key is to start the notes with "who won't be affected", not put them in the middle or near the end, so that users could just skip the rest when it doesn't apply to them. The current information template of the notes is more like

1. there is a high severity vulnerability!
2. explains how it works
3. explain who are affected (at this point, user realize it doesn't matter for them, and this repeats for several vulnerabilities in a row)

I think that can more easily lead to alarm fatigue. A template like

1. there is a high severity vulnerability in an experimental feature (users who don't use any experimental features skips)
2. explain who are not affected (users who don't use this feature skips)
3. explain how it works

may be more optimal in terms of reducing the fatigue, especially when they come out in a row.

from security-wg.

Speaking of "who are affected" and "who are not" and a template for messaging, I also recall that after https://nodejs.org/en/blog/vulnerability/april-2024-security-releases-2 came out, someone reached out to me in private saying that the blog post should also mention that EOL releases are affected. While I am not sure if it's worth the trouble to investigate in detail the extent of impact on EOL releases, it's probably still useful to remind those who are still stuck with EOL releases that in general, EOL releases should be considered affected if they have the affected feature (by not mentioning EOL at all, or emphasizing on active release lines, it seems readers can get the wrong idea that EOL releases are somehow not affected).

from security-wg.