How maintainers experience coordinated disclosure

GitHub Security Lab ran qualitative interviews with open source maintainers between November 2020 and March 2021 to understand how they experience the vulnerability disclosure process and what they think of the security research community. There is no industry-standard disclosure workflow; organizations such as Google Project Zero, GitHub Security Lab, Snyk, HackerOne, and VuSec each run their own. With that fragmentation in mind, the interviews focused on three areas: the maintainer–researcher dynamic, communication preferences, and how maintainers judge and act on reports.

The state of maintainer–researcher relationships

Most interviewees said they have had little or no engagement with security researchers outside of vulnerability reports. A few mentioned incidental contact through Twitter, Slack, Discord, or personal connections in the security space; others described themselves as passive recipients of information from the security community.

When asked what resources security teams could provide, maintainers said they would value foundational “ramp up” material covering:

  • common vulnerability classes and recurring issue patterns,
  • realistic expectations for response times in volunteer-run projects,
  • guides aimed at security researchers, and
  • background on workflows, how security tooling works, and how bugs are typically found.

Maintainers acknowledged the inherent tension between engineering priorities and security priorities. Most described their direct interactions with researchers as generally positive or pleasant, though some characterized the experience as “very obscure” or said it “runs the gamut” depending on the individual researcher.

How maintainers want to hear about vulnerabilities

Constructive feedback is generally welcome, even when it includes negative findings, as long as it is actionable and broadly applicable. Personal attacks are typically ignored or met with explicit boundaries about what the maintainer will discuss.

On notification channels, maintainers voiced a clear preference for private routes. Email notifications work for some, but others described email as “overwhelming” and asked for push notifications instead. One maintainer noted there was no efficient way to route security email to the right person without publishing a personal address in a markdown file — a privacy concern that made them hesitant to post a security policy at all. Another wished for “a way to reach out privately, without needing an out-of-band email.” Public issue trackers are seen as the wrong venue; one participant recalled reports appearing as forum posts with a triumphant “lol” attached.

Initial emotional reactions to a report range from appreciation to stress and alarm, but maintainers generally move to action quickly. One said the first question is always “Oh no, how bad is it now?” and whether they need to drop professional work to fix something critical. Another framed the process positively, noting that users upgrade to the patched release before the CVE is public, so the vulnerability only shows up in the changelog for users who look — and it shows a maintainer who fixed the issue promptly.

A commonly cited ideal report format includes a summary of the problem, an explanation of the specific issue, the potential impact, and remediation advice — the structure GitHub Security Lab itself uses.

How maintainers triage and respond to reports

Private submission is the overwhelming preference. To judge severity, maintainers said they look first at impact — particularly whether the issue enables remote code execution, which one participant said “screams high severity” — and then at code snippets and reproducible steps.

Most maintainers have a designated security contact reachable by email, but most do not yet have a formal security policy in place. They either want to write one or are actively working on it.

On remediation, maintainers do not consider it a researcher’s obligation to provide fixes — but they find it genuinely helpful when offered, since maintainers are often volunteering their time. As for the standard 90-day coordinated disclosure window, most participants called it reasonable, fine, or fair. The consensus is that 90 days is a sensible baseline, but maintainers also want flexibility and a collaborative conversation about timelines rather than a fixed deadline imposed from outside.

Where the research goes from here

GitHub Security Lab has outlined several areas of focus based on this study. The primary goal is strengthening the relationship between open source maintainers and security researchers, which the lab views as essential to securing open source software. Immediate next steps include refining how research is shared with developer communities by producing educational content that frames security topics in a more accessible way. The lab also plans to interview security researchers about their side of the disclosure process to build a more complete picture of how both parties experience it. Early questions from this study about how security is represented visually and linguistically will be developed further, with an eye toward language that resonates with developers.

The lab is inviting feedback on these efforts and has published the full methodology below for those interested in the research details.

Appendix: how the study was run

Between November 2020 and March 2021, nine open source maintainers from projects of various sizes were interviewed.

Finding participants

The study aimed to capture maintainers’ experiences with the security research community. Participants were experienced OSS maintainers, with their tenure ranging from roughly four to 20 years. Recruitment relied on several channels: direct outreach to maintainers who had prior contact with Security Lab researchers, referrals through GitHub programs such as the Top 100 Maintainers Group, Early Access Group, and GitHub Stars, and an open call published on the GitHub blog. Each interviewee was offered a $150 credit to a nonprofit of their choice.

Recruiting developers for security-focused discussions proved difficult. Many maintainers said they did not consider themselves well-versed in security topics or familiar with the vulnerability disclosure workflow. To address this, the researchers used snowball sampling, asking participants for referrals to other potential interviewees. The lab acknowledges that its recruitment experience may not be universal and welcomes perspectives that differ from its own.

Interview process

Each participant took part in a one-hour virtual session covering 13 multi-part questions. The questions were designed to assess maintainers’ broad interactions with the security research community, as well as to solicit specific feedback on the Security Lab’s current vulnerability disclosure process. Sessions were divided into three parts: introductory questions about the participants’ work as maintainers, questions about their dealings with and perceptions of security researchers, and a detailed look at the Security Lab’s disclosure template and workflow. Each interview closed with questions on general industry practices and open discussion time.

Analysis

Interview responses were analyzed qualitatively, with transcripts used to supplement the researchers' understanding of the answers. Each response was coded, and themes were identified on a per-question basis.