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

What is the preferred way to programmatically consume Node vulnerability data? #783

Closed
daxelrod opened this issue Jan 22, 2022 · 6 comments
Assignees

Comments

@daxelrod
Copy link

daxelrod commented Jan 22, 2022

It sounds from #662 and #628 (comment) that the plan is to retire the vuln DB in this repo completely. Once that happens, where will be the best place to get machine-readable data about vulnerabilities in Node itself (the Node.js project, not the third-party ecosystem), in other words, the replacement for https://github.com/nodejs/security-wg/tree/main/vuln/core? And what is the approximate timeline for retirement?

I ask because I maintain an application that I would like to distribute bundled with a Node.js executable on some platforms. I'd like to set up automation to create new releases whenever a new version of Node fixes a vulnerability (but I don't want the churn of releasing on every patch release of Node).

Thank you for the good work you do keeping all of us safer.

@DanielRuf
Copy link
Contributor

The best resources are the CVE databases of MITRE and NVD, the official Node.js blog and https://github.com/advisories?query=node.js which can be all consumed via RSS.

https://nodejs.org/en/blog/vulnerability/

Is this sufficient for your use case?

@daxelrod
Copy link
Author

Thank you for pointing me to those sources!

The information I'd want my automation to consume would be:

  1. Does the version of Node.js I'm shipping have a vulnerability? (handled by the vulnerable field in the vuln database in this repository)
  2. What version fixes the vulnerability? (handled by the patched field in the vuln database in this repository)

It doesn't look like any of the suggested sources do exactly this:

  • It looks like MITRE provides a data dump, but the information in there seems to lag quite a bit behind the Node.js. blog. For example, https://nodejs.org/en/blog/vulnerability/jan-2022-security-releases/ (published Jan 11) mentions CVE-2021-44531, CVE-2021-44532, CVE-2021-44533 and CVE-2022-21824 . However, all of these are still in RESERVED status, meaning they don't have enough information to determine that they affect Node.js nor the affected versions.
  • I believe NVD's API suffers from the same problem. For example, Node 12.22.8 is vulnerable to the above 4 CVEs but querying its CPE has no matches, and it looks like the most recent results for Node at any version were from October. It's totally possible I'm misunderstanding the API or how to form a CPE here, but this is consistent with NVE's guidance that anything that MITRE lists as RESERVED will not appear in their database yet.
  • The official Node.js blog is great in terms of timeliness, but the information about which versions are vulnerable and fixed would need to be scraped out of the freeform text.
  • The GitHub advisory database seems to have lag similar to MITRE and NVE, listing the most recent advisory as CVE-2021-22930, which appeared on the Node.js blog in July but was published to GitHub's database in November. It also has the problem where Node.js is not "from a supported ecosystem with an affected and fixed version" and therefore the versions of Node affected doesn't seem to be in a machine readable field and the fixed version is not listed.

So if these were my options, my best bet would be to try to scrape freeform text.

If I were to scrape the Vulnerability feed, I guess I could look for links in the form https://nodejs.org/en/blog/release/v$major.$minor.$patch and assume that those are fixed versions, and any Node.js at the same major version but a lower minor.patch is vulnerable.

Alternatively, I could scrape release nodes of new Node.js versions (either via the blog or GitHub releases API) and look for either the text This is a security release or CVE.

Would either of those be considered stable interfaces? Thank you very much!

@lirantal
Copy link
Member

If it's just the Node.js runtime versions you'd like to correlate CVEs to then I think this repository is still receiving updates for that, or at least there's a formal place elsewhere to grab them, no?

@richardlau
Copy link
Member

Alternatively, I could scrape release nodes of new Node.js versions (either via the blog or GitHub releases API) and look for either the text This is a security release or CVE.

Would either of those be considered stable interfaces? Thank you very much!

The This is a security release phrase is what we use to set the security flag in https://nodejs.org/dist/index.json (or https://nodejs.org/dist/index.tab): nodejs/Release#437, nodejs/node#27643

@daxelrod
Copy link
Author

If it's just the Node.js runtime versions you'd like to correlate CVEs to then I think this repository is still receiving updates for that, or at least there's a formal place elsewhere to grab them, no?

It's just the Node.js runtime versions I'd like to correlate vulnerabilities and fixes to.

If the plan is for this repository to still receive updates for those, great! If there's a formal place elsewhere to grab them, great! That's my purpose for opening this ticket, to determine where I should grab them going forward.

The This is a security release phrase is what we use to set the security flag in https://nodejs.org/dist/index.json (or https://nodejs.org/dist/index.tab): nodejs/Release#437, nodejs/node#27643

I was not aware of https://nodejs.org/dist/index.json. Is that a stable interface I can use? If so, I could derive what I need from the security field there.

@fraxken
Copy link
Member

fraxken commented Jul 17, 2022

@daxelrod I think yes that's a stable interface (at least I use it in one of my package since few years and i had no issue to date).

I'm closing since you seem to have a solution to your problem.

@fraxken fraxken closed this as completed Jul 17, 2022
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

5 participants