Root Recommendation in Becoming a CNA Guide

[maennchen]

First, thank you for providing the guide "Becoming a CNA as an Open Source Organization or Project". It has been incredibly helpful in navigating the CNA establishment process. ❤️

I noticed that the guide recommends Red Hat as the root CNA for open source projects, but it doesn’t explain the reasoning behind this recommendation. Could you clarify the following points?

• Why is Red Hat specifically recommended as a root CNA over MITRE or other options?
• What advantages, resources, or support does Red Hat provide to open source projects acting as CNAs?
• Are there any differences in tooling or processes when operating under Red Hat as opposed to MITRE?
• Are there known success stories, best practices, or additional resources highlighting the benefits of choosing Red Hat?

Any additional context or guidance would be appreciated as I am trying to make an informed decision on which root CNA to align with.

[pedrohc]

Hello @maennchen,

Red Hat, as a CNA, noted that the CVE Program was well established to support closed source suppliers in its approach and delivery of information. However, as new CNAs are being onboarded under Mitre as the Secretariat, little distribution is made across the other Roots. The representation for open source was unfocused as a group, which diluted their input and contributions, making it challenging to address needs within this large community.

Red Hat applied to become a Root CNA to develop governance focusing on open source software (OSS) needs and approaches and a means to voice those needs. Red Hat uses this approach to invite the community to create unique and different aspects of OSS for the CVE Program to consider.

Our approach is about being open and transparent, allowing the OSS to gather our voice and direction from the CNAs collectively. Becoming a Root requires dedicating staff and infrastructure to build upon that, as this capability is not granted widely.

Red Hat embraced the challenge of initiating a process to bring representation to the OSS community. This initiative is a foundation that the community can use and further develop. The intent is not to be the only way to get there, but rather a starting point.

With over two decades of experience as a member of the CVE Program, Red Hat has significant expertise to both the CVE Program and to our CNAs under the Root. In the CVE Program Roots Council, Red Hat is the only Root designated specifically for open source projects. In contrast, MITRE is the CVE Program Secretariat and also the Top Level Root.

One goal of Red Hat’s involvement in the CVE Program is to improve the way OSS projects manage vulnerability disclosures. As a Root CNA, we can create an opportunity for CNAs to collaborate with other projects and communities. So far, nine open source CNAs chose Red Hat as their Root, and as its mission, we are working to include as many as possible.

Learn more at the Red Hat Common Vulnerabilities and Exposure (CVE) Program page.

The CVE Program defines processes, policies and rules within their work groups, and each CNA must adhere to these guidelines, regardless of the Root they choose. We help CNAs understand and apply these guidelines to their specific contexts as members of the OSS community.

Tooling is also a big concern for us. We are always looking for opportunities to release open source tools that may help the CVE Program and provide support for them. Two examples are the cvelib client for accessing Mitre’s CVE Services API and the cvelint tool for maintaining CVE records quality.

One success story is our quick action to reject CVE IDs wrongly assigned to projects such as curl, which we onboarded as a CNA last year. Check out the Bogus report filed by anonymous to see an example of this success story.

Another example is our security-policy oriented process, which tries to understand each project’s security needs and contexts. Some projects release their own security policies, which are considered in our decisions and mediations, to help avoid or reject wrongly assigned CVE IDs and resolve other types of disputes. We note such cases daily for projects such as glibc and binutils.

Additionally, our engagement is not restricted to the CVE Program. We go above and beyond to support the broader open source community in several ways:

• Following our incident response plan, our experienced Product Security Incident Response Team (PSIRT) helps the community coordinate embargoes and disclosures between many upstreams and researchers.
• We publish many articles, blogs, and other resources describing how we handle security vulnerabilities. Learn more by reading the Red Hat Security Blog.
• Our Open Approach to Vulnerability Management process includes steps to make sure security-related bugs are treated properly by the whole community. This document is updated regularly in an ongoing effort to keep the process evolving.

In conclusion, everything previously outlined, including our philosophy, resources, technical expertise, mentoring, and guidance are available to the CNAs to support and maintain their data quality and operations.

[maennchen]

@pedrohc Thanks for the detailed reply. For me that topic is resolved, but it may make sense to add some details to the guide as well.

Should I close the issue or would you like to keep it around as a proposal to extend the guide?