The Linux kernel has achieved a significant milestone in open source software security. It has been authorized as a CVE Numbering Authority (CNA) by the CVE Program. Being a CNA enables the Linux kernel team to manage the vulnerabilities with more accuracy and higher quality in the future. As Linux Foundation Fellow Greg Kroah-Hartman pointed out in his blog: “This announcement is just the first step, allowing us to be the manager of the CVE allocation process for Linux.”
What is a CVE Numbering Authority (CNA)?
A CVE Numbering Authority (CNA) is a trusted organization authorized to assign unique identifiers, CVE IDs, to security vulnerabilities with a particular scope (a product, project, or component). The CVE IDs allow the broader security community to access detailed information about specific vulnerabilities, facilitating efficient communication and coordination in addressing security threats. This common identifier also helps downstream projects understand what vulnerabilities exist by using a single, unified identifier. Becoming a CNA is a responsibility that underscores an entity’s central role in the cybersecurity world.
How can your organization become a CNA?
Investing in OSS and sharing experiences through OpenSSF has an uplifting effect on other OSS projects. OpenSSF has recently announced the release of the guide to becoming a CVE Numbering Authority as an Open Source project. The guide was released through Alpha-Omega‘s engagement with the Python Software Foundation (PSF) and their Security Developer-in-Residence during PSF’s journey to becoming a CNA.
The guide announcement highlights the CVE-related challenges with open source projects: “For projects whose needs have expanded beyond what’s possible when using existing CNAs, becoming a CNA may be an answer. Some examples include being able to provide high-quality CVE records for users, encouraging researchers to disclose vulnerabilities to the project before receiving a CVE ID, and being able to assign CVEs without sharing embargoed information with other organizations.” While not every project has the resources and time to do this, for those that do, the guide provides a clear path to move forward for projects that desire to control their vulnerability metadata and disclosure process.
Get involved in the OpenSSF Vulnerability Disclosures Working Group
If you find topics like this interesting, you’ll be glad to hear that the OpenSSF has a whole group dedicated to helping collaborate in this coordinated vulnerability space. The Vulnerability Disclosures Working Group has been working with upstream communities, security researchers, and downstream open source consumers for years and has a library of materials and resources that the community can leverage. The Vulnerability Disclosures Working Group is home to documentation and software projects like the Open Source Vulnerability Schema and OpenVEX, an emerging tool to help share information regarding whether software is affected by a specific security vulnerability. If you want to be involved in this community that is involved in and helping shape vulnerability management frameworks, standards, and practices for the whole ecosystem, consider showing up to our working group meetings!