The purpose of this blog is to establish a dialogue and get your input on issues and topics important to CVE. We encourage you to use Medium, LinkedIn, or Twitter to comment on, share, or like a post. Right-click and copy here to share this article from the CVE website.

Our CVE Story: An Open-Source, Community-Based Example

Share or comment

Guest author Mark Cox of Apache Software Foundation has been a CVE Board Member since 2002 and Apache Software Foundation is a CNA.

Several CVE Numbering Authorities (CNAs) have contributed to the “Our CVE Story” blog series on the CVE website. The intention is to educate, anticipate questions, and encourage others to become part of the CVE community. While some CNAs may be more or less similar, each CNA is unique, a little bit different from the others.

The Apache Software Foundation (ASF) has partnered with the CVE Program as a CNA since August 19, 2016. ASF is the world’s largest open-source foundation with over 350 individual projects and thousands of committers. Every Apache project is managed separately, by different people who are all volunteers, including the security teams. Their processes vary, with the foundation only having a few hard requirements on the processes, mostly around creating releases and handling security issues. As you can imagine, that creates some interesting challenges for being a CNA.

In 2020, our security team received over 18,000 emails from which we investigated nearly 1,000 potential vulnerability reports. ASF processes are heavily focused around email so we utilize shared Gmail mailboxes and extensive use of labels for handling incoming security issues with a GTD (Getting Things Done) methodology. Once an issue has been confirmed and accepted by a project, they contact the security team, and we assign appropriate CVE IDs. For 2020, we assigned CVE IDs to 151 issues. More statistics and details of the noteworthy vulnerability events of 2020 can be seen here.

We have a default policy for handling security issues for all ASF projects, which includes ensuring everything that is a security vulnerability in a release is assigned a CVE ID, no matter the severity or if it was found internally or externally, and a common process for disclosures. Until recently, the process required each project to create their own security advisory text and, once an issue is public, submit the CVE Record details to the CVE Program themselves. The security team would allocate names to projects on request from a single ASF pool allocated by the CVE Program. For some projects that only handle one or two issues a year, this was quite a burden to have to learn the right process and formats, and it led to mistakes being made and sometimes fairly substantial delays in getting the CVE Records published.

Our goal then was to eliminate these delays, to get the CVE List updated within a day or less of an issue being published by a project, and to add as much automation as possible. Demands on our project’s security and development teams should be minimal and we should reduce the overheads and cumbersome processes for projects. We want our projects to see handling security issues as something that is easy rather than something they want to avoid.

Our first step towards our goal of simplification and efficiency was to provide a way for projects to capture information about vulnerabilities in a common format we could easily submit to the CVE Program. We started with the Vulnogram tool, hosting a heavily modified version internally and hooking it into the ASF OAuth system used to authenticate our committers. This allows projects to get an overview of all the issues they are currently handling and provides a structured way for them to enter the vulnerability data and generate the advisories and email formats needed by our policy.

The CVE Program’s Automation Working Group (AWG) is the community at work to design, develop and deploy automated capabilities that support the efficient management of the CVE Program. We joined the test group in the AWG to be able to use their new CNA API and made changes to Vulnogram to support it. To that end, we became the first CNA to use the CVE request API to allocate a live CVE ID, so now the ASF security team can use the web tool to allocate a CVE ID for a project and create the vulnerability document ready for them to fill in.

Once a project sets the state of an issue to “public”, it sends a notification to the security team. The security team then uses the JSON format to submit a pull request to the cveproject git repo. The pull request usually gets approved within a few hours, with the CVE website updated soon after.

Going forward, we hope to be a part of the continued collaborative improvement of the program through automation. Some of our future goals include leveraging future APIs to allow us to submit the vulnerability data in JSON format directly from our tool. We are also planning a hybrid approach where we have a set of projects that have been trained on the correct allocation of CVE IDs and will be able to complete all the steps from requesting a CVE ID through to submission all by themselves. Other projects, those that rarely use the process, will get more guidance and review from the security team.

We’ve also just started using the JSON data to generate automated advisory pages for one project, the Apache HTTP Server, and will look at extending this to others too.

Another part of our goal in doing this work is to use the knowledge from our experiences as a bigger CNA to provide feedback to the CVE community. We think this experience and knowledge can help others.

In conclusion, we’re rapidly embracing the recent CVE Program innovations that make the process of handling CVE IDs faster and more efficient. We’re excited by the future prospects that can make handling of security issues less cumbersome, faster, and lightweight. This will not only benefit our projects by freeing up time for our all-volunteer members, but also the users of our projects by ensuring vulnerability information is updated and available quickly and consistently.

Recent Posts

• We Speak CVE Podcast - Partnering with the CVE Program
• My CVE Story: How I Became the CVE Program’s First Vulnerability Researcher CNA (guest author)
• We Speak CVE Podcast - How MongoDB Manages Its CVEs
• Ken Munro of Pen Test Partners Joins CVE Board
• Our CVE Story: Learning to Embrace Recognition and Mitigations of Vulnerabilities as a Strength (guest author)
• More >>