By: Seth Michael Larson (Python Software Foundation), Art Manion (CVE Board)
The Open Source Security Foundation (OpenSSF) is excited to announce a new guide for Open Source projects that are interested in issuing and managing their own CVE IDs through the CVE Numbering Authority (CNA) program. The guide is available on GitHub and will be kept up-to-date with changes to CNA program requirements. Pull requests are also welcome as always.
The guide was primarily sourced from the experiences of the Python Software Foundation (sponsored by Alpha-Omega), and their Security Developer-in-Residence joining the CNA program. Other contributors included the CVE CNA Coordination Working Group (CNACWG), Outreach and Communications Working Group (OCWG), and the OpenSSF Vulnerability Disclosures Working Group.
What is a CVE Numbering Authority (CNA)?
Quoting the CVE Program: “CNAs are vendor, researcher, open source, CERT, hosted service, and bug bounty provider organizations authorized by the CVE Program to assign CVE IDs to vulnerabilities and publish CVE Records within their own specific scopes of coverage.“
CVE IDs for many Open Source projects are issued and managed by a third-party CNA like Red Hat, GitHub, and MITRE. For many projects, this suits the needs for handling a project’s CVE IDs and means that maintainers don’t need to dedicate resources to managing their own CVE IDs and records.
Managing CVE IDs for 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.
There are already multiple large Open Source software projects and organizations which manage their own CVEs such as the Apache Software Foundation, Debian, the Eclipse Foundation, OpenSSL, and more.
It can be difficult to know when a project has reached a level of maturity to be able to manage its own CVEs. By putting all the considerations, requirements, and time commitments into a single document, project maintainers can more easily make the decision without needing to devote time to researching the CVE program. Instead, project maintainers can use the guide to answer many common questions and to match what is required of CNAs with the projects’ level of available people and time. After the decision has been made to apply to become a CNA, the guide also gives a preview of what to expect when onboarding into the CNA program, tips on filling out applications, and suggested resources for training CNA operators.
Becoming a CNA as an Open Source project
CVE IDs are the industry standard for identifying and discussing vulnerabilities in Open Source software. The costs of becoming CNA and maintaining CNA status bring the benefits of greater control over the assignment of CVE IDs and the content of CVE Records. The choice is yours, we hope the guide is helpful.
To learn more about becoming a CNA, see:
About the Authors
Seth Larson is the Security Developer-in-Residence at the Python Software Foundation, Python Software Foundation Fellow, maintainer of popular Python open source packages like urllib3 and Requests, and an advocate for open source sustainability and security.
Art Manion is an active member of the CVE Board and has supported coordinated vulnerability disclosure and analysis efforts at CISA and other U.S. government agencies for more than 20 years. Art is the Deputy Director of ANALYGENCE Labs and previously worked at the CERT Coordination Center (CERT/CC).