Issuing CVEs for the ecosystem

[vdeturckheim]

Now that the Foundation can act as CNA and that the ecosystem triage process is running, it might be a good time to start back discussing about issuing CVEs for the ecosystem.

Would that require some set up on our side?

[mhdawson]

I'm not 100% sure but I think we'd want to handle the assignment of core vulnerabilities separate from those for third party modules. I think the main thing we'd need to do is figure out how to manage our blocks of assigned CVEs. Today the blocks we have assigned are managed in the nodejs-private repo to which there is limited access.

We would also have to extend our scope to cover third party modules but I don't think that would be more than requesting/documenting that.

So what might be required

• figure out where to store/manage CVEs for third party modules
• ask CNA program if we should do anything special with respect to managing blocks
• create a doc like https://github.com/nodejs/security-wg/blob/master/processes/cve_management_process.md for the process for third party modules (we might just update the existing doc, but my first inclination is to keep them separate)
• extend our stated scope, we'd have to update what we have declared as the scope for our CNA.

[ofrobots]

What happens in the case when a given Organization, that happens to be a CNA themselves, has a module on npm with a security vulnerability. Can we be authoritative to issue a CVE for that code?

[lirantal]

@mhdawson I'm leaning towards your first hunch - it seems that the ecosystem (3rd party modules) and Node.js core can be treated differently with regards to CVE management since they probably are different in other cases as well (i.e: security team members, processes, etc).

I'm not sure this is a good example, but looking at the Ubuntu project they have their own Ubuntu Security Notices (USN - https://usn.ubuntu.com/usn/) about specific software in their repos/distributions, which inside it, maps to an actual CVE (this is the same as in Debian RHEL and others too from what I can tell).

I want to mention using the HackerOne platform for this but the process there seems very manual and slow. I had to actually e-mail them with information for a current vulnerability we have and no response still, I assume/hope to get some feedback something in the next few days.

[mhdawson]

Also not stated specifically above but I'd like us to document our proposed process etc (likely through PR's) and then make sure we have TSC review/awareness before landing.

[mhdawson]

@ofrobots I don't think that there should be 2 CNA's that should potentially issue a CVE for the same module/program. We may need to scope ours to be something like "modules for which there is no other CNA coverage", although then the issue is how we "know". Once we document what we want to do I can start the discussion on the CNA mailing list if we need to clarify situations like that.

[reedloden]

Speaking as the guy who assigns CVEs for HackerOne, I'd be happy for Node.js to assign CVEs for ecosystem issues (rather than me). :)

[vdeturckheim]

@mhdawson lgtm. Regarding other CNA, I assume we can see depending on the cases since we usually interact with maintainers during the process.

[vdeturckheim]

We should escalate to TSC with a proposal then create a scope for these CVE. We might want to keep core CVEs and ecosystem CVEs separated.

[vdeturckheim]

@mhdawson do I just need to flag this as tsc-agenda or we need more preparation before that?

[mhdawson]

I think we should write out our proposal with a bit of detail on how it relates to how we issue CVEs for core vulnerabilities. I just send an email with you on CC to get some info from our CNA contact as to how we might keep the two processes separate (issuing for core and issuing for the ecosystem).