On Wed, Nov 5, 2025 at 12:09 PM Olle E. Johansson <[email protected]> wrote:
> > > > On 5 Nov 2025, at 00:23, Greg KH <[email protected]> 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
