Abort when vulnerable flag

[RafaelGSS]

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]

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]

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]

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

[RafaelGSS]

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

[RafaelGSS]

Related topic https://twitter.com/threepointone/status/1627270416615055360

[RafaelGSS]

Hey,

I've been reconsidering and even after releasing https://github.com/RafaelGSS/is-my-node-vulnerable, I still believe it would be a valuable addition to the Node.js core. It will likely gain more adoption, especially since I don't have a large public audience as a regular user. is-my-node-vulnerable got very good feedback and it's pretty stable right now.

That said, I'd love to discuss it again if possible

@nodejs/tsc @nodejs/security-wg

[ljharb]

Would this flag just immediately abort when a node version went out of support, even if there weren't any vulns in it?