Re: Becoming a CVE Naming Authority for your project

[Pedro Sampaio <psampaio () redhat com>]

On Wed, Nov 5, 2025 at 12:09 PM Olle E. Johansson <oej () edvina net> wrote:

> > On 5 Nov 2025, at 00:23, Greg KH <greg () kroah com> wrote:
> >
> > On Tue, Nov 04, 2025 at 08:47:35AM -0300, Rodrigo Freire wrote:
> > > Open Source Project Maintainers,
> > >
> > > Managing security vulnerabilities is currently a significant pain,
> > > especially with the recent increase in dubious CVE reports due to AI
> > > assistants. The discussion around questionable CVEs reported against
> > > projects like dnsmasq, curl highlights a growing concern within the
> > > open source community.
> > >
> > > One effective way to combat the influx of bogus CVEs and ensure
> > > accurate vulnerability reporting is for open source projects to become
> > > their own CVE Numbering Authority (CNA). As a CNA, your project gains
> > > control over the CVE assignment process.
> > >
> > > Taking ownership of your project's as a CNA ensures that you are in
> > > control of the CVE assignment. There will be some requirements to it,
> > > sure thing. Check
> https://openssf.org/blog/2023/11/27/openssf-introduces-guide-to-becoming-a-cve-numbering-authority-as-an-open-source-project/
> > I totally agree that all "major" open source projects should become a
> > CNA, and strongly recommend taking back control over stuff like this.
> >
> > But, for "smaller" open source projects, it would be _great_ if a root
> > CNA could become the default for all of open source so that we don't
> > have the problem where any CNA can assign CVEs against any random
> > software without any repercussions.
>
> I would be happy if we could assign or “scope” to a CNA that would help us,
> but also protect our scope without having to become a CNA with all that
> comes with being one. In that case, we have to be in control over our scope
> if we want to move it to another CNA or at some point have the resources
> needed to register as a CNA ourselves. I am not sure how scope “ownership”
> works in the CVE program today.
>
> /O

The CVE Program has an hierarchical structure[1] which also affects the
scope definition. The higher levels would always have a wider scope that
can encompass the scope of the lower levels. So by becoming a CNA, one
could protect itself from other CNAs at the same level, but not from higher
levels. And I think it is this way so we can have routes to escape any
abuses, while still allowing disputes to happen.

The scope of a CNA is defined during its onboarding, through a simple
statement that describes everything which it is responsible for. Usually
vulnerabilities in whatever software/systems are maintained by the
candidate entity, or if the candidate is a researcher group, whatever is
found by it and is not in another CNA scope.

I believe it is more than proven by now, that the OSS ecosystem has its
particular needs in regards to the CVE/PSIRT functions in relation to
others, and a specific environment/rules needs to be created for it. One
example would be that OSS projects can create their security policies
(could be as simple as a SECURITY.md file), and those should be followed by
all CNAs when making assignment decisions, within reasonable context, even
if the project is not a CNA itself.

So having an overseeing CNA for OSS would also have to be accompanied by
the creation of that environment IMO.

[1] https://www.cve.org/programorganization/Structure

-- 
Pedro Sampaio | Red Hat Product Security
851525C5A98E9DEB7E650ABDFAC8296FBC674B8F