Vulnerability reports come at open source project maintainers from all directions with varying levels of quality and detail — from public project issues to emailed reports, and sometimes even through social media. This presents a considerable challenge for open source software (OSS) maintainers. How do you ingest, track, and triage external vulnerability reports in a consistent manner, especially when most OSS is run by volunteers in their spare time? 

The vulnerability research ecosystem contains many different actors, all with different motivations, ranging from commercial to altruistic to everything in between. 

Effectively and consistently interacting with the security community can prove challenging. Through the GitHub Security Lab (disclosure: I am a GitHub employee), we've observed many different approaches to receiving and triaging vulnerability reports, ranging from casual email interactions to fully ticketed bug tracking systems.

I'll break down the vulnerability report pipeline into five major steps that make for an effective and positive experience for both the maintainer and external vulnerability reporter: Receive, Acknowledge, Verify, Triage, and Publish.

Receiving Vulnerability Reports
Clearly indicate how and where you want to receive vulnerability reports, regardless of available resources, to help avoid friction, lost reports, or the publication of unresolved reports.

Setting a security policy will help standardize and normalize how vulnerability reports are delivered and how you want to track them further. By setting a policy, or otherwise making reporting instructions available (for example, in your project's ReadMe), you can take ownership of the process from the beginning. You'll also find that most external vulnerability reporters are more than happy to take direction when explicitly provided.  

Acknowledging Vulnerability Reports
Once a vulnerability report is received, either publicly or privately, it's important to acknowledge the receipt as quickly as possible. Even if no immediate resources are available for additional investigation, this initial acknowledgment allows vulnerability reporters to queue the status of the report on their end. Depending on the style of disclosure (full vs. coordinated), the reporter may start a clock on the publication deadline for the vulnerability details. 

The GitHub Security Lab follows a coordinated disclosure process in which maintainers get 90 days to privately triage a vulnerability report, after which full details of the issue are published in a public advisory. Rapid acknowledgment of a received report indicates to the reporter that you're quick to respond and act, and it sets a positive tone for the rest of the interaction.

Verifying Vulnerability Reports
Involve the vulnerability reporter when verifying the impact and veracity of the report. Chances are, they have already spent significant time considering the vulnerability in a variety of scenarios, some of which you may not have considered.

Ask for additional context on how they think a vulnerability could manifest in your project and any proof-of-concept or configuration details to determine whether the reported issue is indeed something with a security impact on your project. Sometimes you will disagree on whether or not something is a vulnerability or whose responsibility the vulnerability is. The most productive way to approach these scenarios is through dispassionate technical debate. 

Remember, while external vulnerability reports can feel like attacks on code quality, vulnerability reporters are often handling large volumes of reports concurrently, and they are unlikely to have personal investment in your specific project. You both share a common goal to first establish whether an issue is in fact a vulnerability, and if so, to get that issue resolved. Treating the reporter as a contributor, as opposed to an external critic, sets an effective tone for the interaction.

Triaging Vulnerability Reports
After verifying the report and reaching a consensus on its impact, it's time to discuss remediation. You and the reporter may also have differing opinions on the approach, so you should correct the issue in a way that you see fit while taking the reporter's concerns into careful consideration. The reporter will often have knowledge of corner cases and remediation bypasses that are easy to miss without a security research background. Once you believe an issue is fixed, have the reporter review your proposed remediation in case there are additional insights that can result in a stronger fix.

Publishing Vulnerability Reports
An important yet sometimes missed step in the disclosure pipeline is to ensure the wider ecosystem becomes aware of the issue and its remediation. It is not uncommon for projects to fix a recognized security issue in the current development branch but then not explicitly designate the commit or subsequent release as a security fix or release. This can lead to issues, as consumers of your project and any downstream dependencies might only update based on available security updates. Assuming that downstream consumers will always run the latest version of your project can lead to unnecessary proliferation of vulnerable code.

The reporter will often publish their own advisory, but you can take ownership of this process too. Commonly, a Common Vulnerabilities and Exposures (CVE) number will be requested and assigned by either the vulnerability reporter or yourself in the verification phase. 

On GitHub, you can publish a GitHub Security Advisory (GHSA) for your project, and since GitHub is a CVE Numbering Authority (CNA), the process is made easy. Publishing a GHSA makes your advisory available to the GitHub Advisory ecosystem and the wider OSS security ecosystem through its CVE. The assignment of the CVE, and details provided within, helps ensure there is ecosystem awareness of the security fixes available for any downstream consumers. 

Security vulnerabilities often go undetected for more than four years before being disclosed. Improving how you interact with vulnerability reports and reporters can help ensure that issues don't remain unresolved for longer than they need to. While effectively triaging external vulnerability reports may seem daunting, even projects and maintainers with limited resources can create a standardized pipeline for receiving, acknowledging, verifying, triaging, and publishing vulnerability reports. By removing ambiguity from the process, you can turn vulnerability reporting into a positive and collaborative experience, benefiting both the vulnerability research and developer communities and ultimately, OSS security.