-
Notifications
You must be signed in to change notification settings - Fork 10
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
Comments
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. |
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? |
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. |
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 |
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. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Uh oh!
There was an error while loading. Please reload this page.
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.
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.
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.
The text was updated successfully, but these errors were encountered: