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 ReportsClearly 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 ..
Support the originator by clicking the read the rest link below.
