Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Abort when vulnerable flag #852

Closed
RafaelGSS opened this issue Dec 16, 2022 · 5 comments
Closed

Abort when vulnerable flag #852

RafaelGSS opened this issue Dec 16, 2022 · 5 comments

Comments

@RafaelGSS
Copy link
Member

As previously discussed in #846. I'm creating this issue to discuss the possibility of including a flag (--abort-when-vulnerable) that will abort the node.js process if the version contains a known vulnerability.

The idea is pretty simple: perform a remote call and check against our database: https://github.com/nodejs/security-wg/tree/main/vuln/core if the version in use is vulnerable. We will need to include more metadata such as the operating system, but that's easy to do.

A similar discussion is in progress on nodejs/node#44942 and one of the concerns raised was the necessity to perform a remote call. However, since this feature is also opt-in, I don't see why it could be a problem.

Just to summarize:

  • A flag that will abort the process if the current version is vulnerable
    • If not, the process will also be exited with status code 0 - My personal opinion is to exit anyway to avoid misunderstanding such as: "I started my webserver yesterday and today a new vulnerability was found and fixed, my process wasn't aborted".
    • I expect people would run it in their CIs

While it could just as easily be a module, I don't think it would be as reliable as having it as an option in Node.js. But, of course, I'm open to discussing it.

I'm tagging @nodejs/tsc to get more visibility on it before any work.

cc: @nodejs/security-wg

@tniessen
Copy link
Member

While it could just as easily be a module, I don't think it would be as reliable as having it as an option in Node.js.

What's the reasoning behind this? If node --abort-when-vulnerable exits either way, how is it better than npx -y is-my-node-vulnerable? (Sure, node might have fewer vulnerabilities itself than npx or is-my-node-vulnerable, but if there is a TLS vulnerability in node, the first command is hazardous as well.)

@RafaelGSS
Copy link
Member Author

RafaelGSS commented Dec 16, 2022

While it could just as easily be a module, I don't think it would be as reliable as having it as an option in Node.js.

What's the reasoning behind this? If node --abort-when-vulnerable exits either way, how is it better than npx -y is-my-node-vulnerable? (Sure, node might have fewer vulnerabilities itself than npx or is-my-node-vulnerable, but if there is a TLS vulnerability in node, the first command is hazardous as well.)

I mean, I'm fine with a separate module, I just don't think people are going to use it. That's pretty much the same analogy for --check-updates.

Neither do I think we should include that flag based just in my guess. We're going to discuss it on Security-WG. I'll elaborate on it soon.

@RafaelGSS
Copy link
Member Author

Discussed it on Security WG 05/01 - I'll proceed with a separate module and see how it goes.

@RafaelGSS
Copy link
Member Author

So, I built it https://github.com/RafaelGSS/is-my-node-vulnerable. Let's see how the community adopts it.

@RafaelGSS
Copy link
Member Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants