[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADz+4x-GmS6gSGRe=6jCkS+5Sgnx8SpVyvx8Lu5UDE6ndx9CzQ@mail.gmail.com>
Date: Thu, 6 Nov 2025 12:17:41 -0500
From: Pat Gunn <pgunn01@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Becoming a CVE Naming Authority for your project
Wouldn't it be more healthy if security-minded people preferred to decouple
process, numbering, and naming of these kinds of issues from
technical/legal ownership of the covered products? I recognise that there's
an advantage of the technical/legal owners generally having more context,
but they're also not (and can't be, no matter how much relevant engineers
might promise to adhere to some code rather than financial/reputational
interests of their employer) uninterested in the process. It would be
easier to trust the process if it were generally vendor independent - if
for example Redhat, a company that's been particularly poor at being a good
open citizen recently, didn't want something affecting its products to be a
CVE because in this hypothetical they were doing marketing around how few
CVEs there are on their product, would we be okay with that? Would that
look like good practice of the security community? More independence would
possibly prevent such things.
Hoping I'm not missing something obvious about this concern that'll make me
look the fool, but worried that if nobody speaks up about it this will
amount to a corporate capture of things that are best not so owned.
On Tue, 4 Nov 2025 at 11:09, Rodrigo Freire <rfreire@...hat.com> 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/
>
> If you want to learn more and how it impacted an open source project,
> reach for the glibc (in the past, a frequent topic here in this
> mailing list) security community
> (https://sourceware.org/glibc/security.html) and ask them your
> questions.
>
> If you're interested in learning more about becoming a CNA, Red Hat
> (along Google, INCIBE, JPCERT/CC, and Thales Group) can help you.
> Reach ymittal@...hat.com and we will be happy to help.
>
> Best regards;
>
> Rodrigo Freire
> Chief Architect
>
>
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
