search

openjs-foundation / security-collab-space

a repository for documenting and coordinating the foundation's security collaboration space
Apache License 2.0
24 stars 8 forks source link

CVE Challenges for OpenJS Projects #102

Closed ruddermann closed 9 months ago

ruddermann commented 9 months ago

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.

  1. 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.

### Tasks
mcollina commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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

wesleytodd commented 9 months ago

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 commented 9 months ago

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.