Comments (9)
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."
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
- there is a high severity vulnerability!
- explains how it works
- 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
- there is a high severity vulnerability in an experimental feature (users who don't use any experimental features skips)
- explain who are not affected (users who don't use this feature skips)
- 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.
Related Issues (20)
- OpenSSF Scorecard Report Updated!
- OpenSSF Scorecard Report Updated!
- April 3, 2024 security releases have not been announced on the nodejs-sec mailing list HOT 2
- dependabot suggesting pre-release update HOT 2
- Can we have "unsecure" features in Node.js? HOT 5
- Node.js Security team Meeting 2024-04-11 HOT 5
- OpenSSF Scorecard Report Updated!
- Collaborators Inactivity Policy Review HOT 3
- Question: Why do we have a `--experimental-policy`? HOT 4
- HackerOne page does not mention the threat model HOT 1
- Require optional PoC videos from hackers to help triaging reports
- Node.js Security team Meeting 2024-04-25 HOT 1
- More control over remote debugging (and killing) HOT 4
- Threat Model question about Permission Model HOT 2
- Security Vulnerability to report HOT 1
- OpenSSF Scorecard Report Updated!
- OpenSSF Scorecard Report Updated!
- Adding language to Bug Bounty program to differentiate "security features" from "defense in depth features" HOT 1
- Permission Model adoption from Package Managers HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from security-wg.