Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

CVE Challenges for OpenJS Projects #102

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

Closed
ruddermann opened this issue Feb 4, 2024 · 6 comments
Closed

CVE Challenges for OpenJS Projects #102

ruddermann opened this issue Feb 4, 2024 · 6 comments
Assignees
Labels
dga Data Gathering & Analysis

Comments

@ruddermann
Copy link
Collaborator

ruddermann commented Feb 4, 2024

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
@ruddermann ruddermann added security-agenda security-destf Issues and tasks related to the German Sovereign Tech Fund labels Feb 4, 2024
@ruddermann ruddermann self-assigned this Feb 4, 2024
@mcollina
Copy link
Member

mcollina commented Feb 5, 2024

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
Copy link

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
Copy link
Member

mcollina commented Feb 8, 2024

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
Copy link
Member

joesepi commented Feb 12, 2024

@wesleytodd
Copy link

@mhdawson
Copy link
Member

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.

@openjs-foundation openjs-foundation locked and limited conversation to collaborators Feb 16, 2024
@ruddermann ruddermann converted this issue into discussion #104 Feb 16, 2024
@ruddermann ruddermann added dga Data Gathering & Analysis and removed security-agenda security-destf Issues and tasks related to the German Sovereign Tech Fund labels Feb 20, 2024
@ruddermann ruddermann added this to the DESTF Milestone 4 milestone Feb 20, 2024
@ruddermann ruddermann moved this to Active Discussion in DESTF - Security Project Tracking Feb 20, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
dga Data Gathering & Analysis
Projects
Status: Active Discussion
Development

No branches or pull requests

5 participants