From: MITRE TL-Root

Hello curl CNA Team,

We have received the dispute escalation below and initiated the CVE Program Policy and Procedure for Disputing a CVE Record....

tldr: Reporter thinks their report should get a CVE while we think not. It's probably prudent that I don't share the details until it is resolved.

@bagder Is this the first time someone escalated?

@kidney yes. But we've only been a CNA for two years

@bagder Did they get their report closed as AI slop previously and are pissed about that?

@Stephanie no, we just didn't consider the flaw CVE material because of the circumstances - but they insists...

@bagder @Stephanie everyone wants a CVE on their CV! We had to battle with a reporter recently who wanted a 7.7 severity bug in fwupd to be a CVE, but in reality it was a documentation fix.

I really think we need some way of disputing these kind of things without all the overhead of becoming a CNA...

@hughsie @Stephanie ... we (curl) *are* a CNA. It is still disputed as they can just take it to the next level in the hierarchy. Theoretically, it should be possible to handle disputes properly without being a CNA but in reality the CVE system really encourages everyone to become a CNA to properly police their own backyards.

@bagder @Stephanie so in your opinion, *should* large open source projects like fwupd become a CNA too? If so, is there any "quick start guide" or "list of gotchas" that you'd recommend? Thanks.

@hughsie @Stephanie put simply: yes I recommend that. I've seen @sethmlarson and @gregkh do the same. It really is not hard, there is no fee and once aboard, very little extra overhead.

OpenSSF publishes this guide, I believe based at least partly on Seth's initial work:

https://github.com/ossf/wg-vulnerability-disclosures/blob/main/docs/guides/becoming-a-cna-as-an-open-source-org-or-project.md

@bagder @Stephanie @hughsie

We did that in OpenVPN too. We got CVEs issued on reports we rejected, because the reporter then reached out directly to MITRE because the reporter disagreed it wasn't an issue. One of them was also something being a documentation issue (a user explicitly configuring a management interface, which is disabled by default, on a public IP address and not ensuring password authentication is enabled is hardly a CVE).

Since Red Hat is a CNA these days available for FOSS projects, perhaps that is a better approach getting under their wings. That was not an option for us when we registered.

The gotchas is the administrative overhead of the keeping track of the status for the CVEs in progress internally, keeping reporters up-to-date, discussing (sometimes arguing) the report and the progress. Some (few) reporters expects a resolution within a week with a loud announcement crediting them. Once its made public, there is less work with it. Then its to fix the CVSS scores when they're completely wrong, typically added by some external entities if you didn't put it in the CVE record yourself.

We also have a policy to never credit reporters in the CVE record itself, even though it seems to be possible now. We give them a simple "reported by" line in the release announcement and/or the git commit message. Not because they don't deserve it, but to make it less attractive for those doing reports mostly to get CVEs in their CVs and being easily searchable. Those reports are also typically not the most critical ones, but minor stuff. Some reporters has even demanded more attention (which we've politely rejected, due to our policy).

At its core, it's tediously and boring administrative work which unfortunately is needed to keep some kind of control. This work also takes away time which could be used on development of the project.

It's the ego-trip reporters who are the biggest pain, though, which wastes our time most, though. And they are far more loud than the serious reporters, which can wonderful to collaborate with. If everyone would behave as the really serious reporters, it wouldn't be so annoying work.

@hughsie @bagder @Stephanie If you want a CVE for your CV, come fix a Linux kernel bug! We are giving out 13 CVEs a day, plenty to go around for everyone! :)

@bagder @hughsie @Stephanie @sethmlarson I second this, @hugsie, you should become a CNA for fwupd. The application process is relatively painless (sit through a presentation, fill out some sample CVEs to prove you know what you are doing, and submit a few testing CVEs to show you know how the tools work).

The OpenSSF guide is great, and a huge shoutout to Python for paving the way for us all to be able to do this.

@gregkh @bagder @hughsie @Stephanie pays quite well if you can find a real exploitable hole in some areas too with various bugs bounties

@gregkh @bagder @hughsie @Stephanie Thank you both for the kind words.

Just to echo Daniel and Greg's recommendations: I believe even medium-sized projects may want to consider becoming a CNA.

It's totally valid to be a CNA and never touch Vulnogram or manually fill out CVE records. You can become a CNA just to point reporters to your security policy and then delegate the actual recordkeeping to another CNA like Red Hat or GitHub, for example.

@n0toose @bagder @hughsie @Stephanie Of course, public fixes for public bugs is the huge percentage (like 99%) of all of our security fixes that end up getting accepted and later assigned a CVE.