OpenJS Projects and CVE Numbering Authorities

[ruddermann]

In the #express channel, @wesleytodd brought up challenges they've had related to CVEs being issued by Mitre's CNA without coordination. He mentioned that OpenJS once had a Package Vulnerability Management & Reporting Collab Space that this could fit under if we wanted to bring it back to life.

Problem

Random people on the Internet can submit CVEs to Mitre. These CVEs may not be accurate, correct, or even necessary. Unfortunately, the way the CVE Program is structured, if there is no specific CVE Numbering Authority (CNA) for a piece of software, other CNAs can can issue CVEs without input from the owner of that software.

Solution(s)

There are only a couple of solutions to this, which warrant discussion.

1. Foundation Projects that are experiencing this issue and have the internal capacity can become their own CNAs. This is the approach Node.js has taken.

The upside of this approach is that Projects can do this as needed, with OpenJS providing support to get things going. The downside of this is that Projects would need to manage issuing CVEs on their own.

2. OpenJS can become a CNA for all Foundation Projects that are not already their own CNA.

The upside of this approach is that it doesn't put much/any burden on Projects, but does put OpenJS in the critical path to issuing CVEs.

[mcollina]

Managing a CNA is work. Who would do it? Note that having a CNA doesn't really stop other CNA for emitting CVEs, but it gives a sense of authority when disputing.

Node.js is currently not using its CNA status, we created our CVEs via HackerOne.

[wesleytodd]

but it gives a sense of authority when disputing.

I believe this is the main goal anyway right? Without the ability to properly dispute (as most of our projects are unable to do) we are at the mercy of the other CNA's and the security researchers reporting the issues.

It sounds like for Node.js the maintenance of the CNA is not an issue, is that correct? It was just the setup that was "work"? If so, then could we not apply the same thing to any foundation project and use a shared CNA for all of them? Then we could use HackerOne as well just like Node.js does?

[mcollina]

Unless you have a custom security flow (with private repository, multiple release lines and private CI), I would recommend to use GitHub security reporting. GitHub allocates the CVEs with the click of a button.

[joesepi]

FYI: https://openssf.org/blog/2023/11/27/openssf-introduces-guide-to-becoming-a-cve-numbering-authority-as-an-open-source-project/

[wesleytodd]

Looks like that article links to this as the actual "guide": https://github.com/ossf/wg-vulnerability-disclosures/blob/main/docs/guides/becoming-a-cna-as-an-open-source-org-or-project.md

[mhdawson]

Node.js is currently not using its CNA status,

I'm not sure that is quite right. We are not using the traditional CNA CVE creation workflow, instead we use H1 for that. However, if anybody else issues a Node.js CVE I'd be asking how they could do that without consulting the project. So in that sense we are still leveraging our CNA status.

[ruddermann]

@mhdawson: Correct, being a CNA prevents anyone else from issuing CVEs about you. It doesn't prevent you from issuing CVEs from a different CNA, which is common for many paid users of the bug bounty platforms).

[ruddermann]

Hey everyone! I've converted this Issue into a Discussion. I hope you like it - feedback is welcome! Just put it in a reply to this comment!

Thanks everyone!

[ruddermann]

To get a sense of what's happened in the past, I've gone back and found what I hope are all of the CVEs for nearly all Security Priority 1 and 2 Projects, except for jQuery and Node.js.

There are a number of projects that have suffered from unilateral CVEs, but none more than JerryScript. Most CVEs for JerryScript are unilateral and 19 CVEs created in 2023 are not fixed (regardless of validity). You can check the raw data on this Google Sheet.

OpenJS Project	COUNT of CVE
Appium	2
Dojo	18
Electron	24
Express.js	5
Fastify	22
Grunt.js	4
JerryScript	91
jshttp	3
lodash	7
loopbackio	2
Moment.js	4
node-red	4
pillarjs	4
webpack	5
Grand Total	195

[ruddermann]

Thanks for the consensus and support from the Security Collab Space regarding the question of OpenJS becoming a CNA! Also, here is the deck that was presented.

In particular, thanks to @UlisesGascon and @ljharb for their enthusiasm volunteering to be CNA POCs and take the required CNA training and interview with Red Hat with me! Anyone else interested is more than welcome to join.

To quickly level-set folks who weren't at the meeting, here's what OpenJS becoming a CNA means:

• Those outside of OpenJS and OpenJS Projects won't be able to unilaterally issue CVEs against OpenJS Projects anymore.
• OpenJS Projects are free to continue following their existing CVE processes using Github Security Advisories/HackerOne/etc.
• OpenJS Projects will have some transitionary tasks over the medium-term, but building consensus and implementing these will be iterative and doesn't need to block becoming a CNA.

To start before we can reach out to Red Hat/Mitre to start the process, there are things to do so we can complete their initial CNA Application Form (check out this gDoc to see what is needed and what I have so far):

• Develop/approve an OpenJS-level Disclosure Policy for the OpenJS website (eg: openjsf.org/security or another URL if folks prefer)
• Develop/approve the formal OpenJS CNA Scope language for cve.org
• Identify an easy-to-update solution to list all published OpenJS CNA CVEs (eg: a public mailing list or updating a page via PR)
• Set up a public security point of contact email address and private mail group for CNA POCs and TBD others (eg: something like security@)
• Given these events, what is the best next step the Node.js CNA?

Questions for Discussion:

• What do we use to maintain the CNA's public list of CVEs?
• Who would like to/should be a member of the security point of contact's private mailing list?

(Tagging relevant folks who may not be aware of this discussion thread: @kyliewd @rginn @bensternthal @ctcpip @marco-ippolito @jdalton)

[ctcpip]

Thank you Rudd for the detailed summary and taking the lead on this. I'm happy to join Rudd, Ulises, and Jordan as CNA PoCs.

What do we use to maintain the CNA's public list of CVEs?

A GitHub md file, which can optionally be published via GH pages, would be the least friction solution to start with. The big question is what is the best repo for this? (existing, new, etc.)

It sounds like the first thing to tackle is the disclosure policy, and I think we already have a great head start on that with the work Rudd has already done on model disclosure policy for OpenJS projects.

I think I am getting ahead of things here though. As I recall, this is pending further review in the CPC.

[ruddermann]

woot - thanks for volunteering @ctcpip!

Your suggestion is probably the best, modern way and allows easy automation and change tracking. Regarding discoverability:

• At the minimum this gh file could be directly linked from openjsf.org/security
• Even better if this file could be used as a data source and displayed on openjsf.org/security/advisories

[ruddermann]

Next Steps from the 9 Sept Collab Space Meeting (#232)

@rginn: wrt EMCAScript in CNA Scope talk to OpenJS Legal
@ctcpip: wrt EMCAScript, assuming CNA Legal approves, get topic on agenda for ECMAScript meetings in early October
@ruddermann: coordinate with nodejs to deprecate the Node.js CNA
@ruddermann: create task+document next steps on cna@ and security@ mailing lists
@ruddermann create task+document next steps on creating security advisories Github page
@ruddermann: create task+document on documenting CNA processes (eg: publishing CVEs, how projects engage with us)
@ruddermann: coordinate public comms with @rginn and Jen Shelby