Improve the vulnerability reporting process with …
Vulnerability reports are sent to open source project maintainers in all directions with varying levels of quality and detail – from public project issues to reports sent by email, and sometimes even via social media. This presents a considerable challenge for maintainers of open source software (OSS). How do you ingest, track, and sort out external vulnerability reports consistently, especially when most free software is run by volunteers in their spare time?
The vulnerability research ecosystem contains many different players, all with different motivations, ranging from business to altruistic to everything in between.
Effective and consistent interaction with the security community can be difficult. Thanks to the GitHub Security Lab (disclosure: I’m a GitHub employee), we’ve seen many different approaches to receiving and sorting out vulnerability reports, from occasional email interactions to fully logged bug tracking systems.
I’m going to break down the vulnerability reporting pipeline into five main stages that enable an effective and positive experience for both the maintainer and the external vulnerability reporter: receive, acknowledge, verify, sort, and publish.
Receipt of vulnerability reports
Clearly indicate how and where you want to receive vulnerability reports, regardless of available resources, to avoid friction, lost reports, or the publication of unresolved reports.
Defining a security policy will help standardize and standardize how vulnerability reports are delivered and how you want to monitor them further. By setting a policy or making reporting instructions available (for example, in your project’s readme file), you can take ownership of the process from the start. You’ll also find that most external vulnerability reporters are more than happy to follow directions when explicitly provided.
Recognition of vulnerability reports
Once a vulnerability report is received, whether in public or private, it is important to acknowledge it as quickly as possible. Even if no immediate resources are available for further investigation, this initial acknowledgment allows vulnerability reporters to queue the report status on their own. Depending on the style of disclosure (full or coordinated), the reporter may start a clock on the release deadline for the details of the vulnerability.
The GitHub Security Lab follows a coordinated disclosure process in which officials have 90 days to privately sort out a vulnerability report, after which full details of the issue are published in a public notice. Prompt acknowledgment of a received report lets the reporter know that you are reacting and acting quickly, and it sets a positive tone for the rest of the interaction.
Verification of vulnerability reports
Involve the vulnerability reporter when verifying the impact and veracity of the report. There’s a good chance they’ve already spent a lot of time looking at vulnerability in various scenarios, some of which may not have been considered.
Ask for additional context on how they think a vulnerability might manifest in your project and any proof of concept or configuration details to determine if the reported issue is indeed impacting the security of your project. Sometimes you will disagree on whether or not something is a vulnerability or who is responsible for the vulnerability. The most productive way to approach these scenarios is through a relaxed technical debate.
Keep in mind that while external vulnerability reports can look like attacks on code quality, vulnerability reporters often process large volumes of reports simultaneously and are unlikely to personally invest in your specific project. You both share a common goal: to first determine whether an issue is in fact a vulnerability and, if so, resolve that issue. Treating the journalist as a contributor, as opposed to an outside critic, sets an effective tone for the interaction.
Sort vulnerability reports
After checking the report and reaching a consensus on its impact, it is time to discuss corrective actions. You and the reporter may also have differing opinions on the approach, so you should correct the issue in a way you feel is appropriate while carefully considering the reporter’s concerns. The reporter will often be aware of corner cases and correction bypasses that are easy to miss without security research training. Once you believe an issue is resolved, ask the reporter to review your correction proposal in case there is any additional information that could lead to a more solid solution.
Publishing vulnerability reports
An important, but sometimes missed, step in the disclosure process is to ensure that the wider ecosystem becomes aware of the problem and its resolution. It is not uncommon for projects to fix a recognized security issue in the current development branch, but not explicitly designate the commit or later as a patch or a security release. This can cause problems because consumers in your project and all downstream dependencies can only update themselves based on available security updates. Assuming that downstream consumers will always be running the latest version of your project can lead to unnecessary proliferation of vulnerable code.
The reporter will often post their own review, but you can take ownership of this process as well. Generally, a CVE (Common Vulnerabilities and Exposures) number will be requested and assigned either by the vulnerability reporter or by yourself during the verification phase.
On GitHub, you can post a GitHub Security Advisory (GHSA) for your project, and since GitHub is a CVE Numbering Authority (CNA), the process is streamlined. The publication of a GHSA makes your opinion available to the GitHub Advisory ecosystem and the wider OSS security ecosystem via its CVE. The attribution of the CVE and the details provided within it helps ensure that the ecosystem is aware of the security patches available to all downstream consumers.
Security vulnerabilities often go unnoticed for more than four years before being disclosed. Improving the way you interact with vulnerability reports and reporters can help ensure that issues don’t go unresolved longer than necessary. While the effective triage of external vulnerability reports can seem daunting, even projects and managers with limited resources can create a standardized pipeline to receive, recognize, verify, sort, and publish vulnerability reports. By removing ambiguity from the process, you can turn vulnerability reporting into a positive, collaborative experience, benefiting both the vulnerability research and development communities and, ultimately, OSS security.
Bas Alberts is a Senior Security Researcher in the Security Lab team at GitHub with an information security background focused on breaches. See full biography