But a team member’s GitHub account was flagged as spam for opening 15 issues and 15 pull requests. “We did let [GitHub] know that this wasn’t an automated process of any kind. We manually created the issues and pull requests,” Nagappan says. “We were open with GitHub. We told them, we’re a research team and this is what we’re doing.”

The experience prompted the team, which included Nagappan, Prakash, and collaborators at the University of Illinois at Urbana-Champaign, to do a study (published 23 May) to investigate the prevalence of vulnerable dependencies and the difficulties in reporting them. They analyzed 600 open-source Java projects on GitHub and found that 64 percent (385 of 600 projects) used at least one vulnerable library. Moreover, only 19 projects (3 percent) had some kind of reporting process—be it a “bug bounty” program, an email address to contact regarding security vulnerabilities, or a web form for submitting security issues.

To address the lack of a standardized method to report security vulnerabilities in GitHub projects, the team recommended adding a SECURITY.md file which contains contact information and the disclosure policy of a project. The team also suggested support for submitting pull requests or issues visible only to project owners (also called maintainers) as a way to privately disclose potential security problems.

Coincidentally, the team’s research was made available online on the same day that GitHub released new security features, which include a security policy and maintainer security advisories.

“Open-source projects are often run by individuals who do this in their spare time, without pay, and they don’t have the support they need to disclose security issues properly,” says Justin Hutchings, senior product manager of security at GitHub. “In many cases, there’s also a stigma associated with having had a security issue. We built maintainer security advisories and support for security policy to change that because security issues are something every project has to deal with, but responsible disclosure of security issues is critical to ensure we’re protecting users.”

GitHub’s security policy involves the same SECURITY.md file recommended by Nagappan and his team. Meanwhile, maintainer security advisories, which the company describes as “a private workspace to discuss, fix, and publish security advisories,” are similar to the research team’s suggested private pull request feature.

“It’s an interesting coincidence,” Prakash says. “Nevertheless, I think the paper gives data which substantiates why it makes sense to do something like this.” Nagappan agrees, adding that the team was pleased to provide hard evidence behind the problem.

Hutchings says the company wasn’t aware of the team’s study. “But that’s not to say GitHub came up with the features in total isolation. We are continually working closely with customers, partners, and members of the open-source community to better understand the pain they’re feeling,” he says. “That feedback drives prioritization, and ultimately iterative prototyping on solutions that we then go and validate with customers.”

Prakash hopes a standard reporting process for security vulnerabilities, such as that created by GitHub, will improve the security of open-source projects in the long run. “What you don’t want to see is a SECURITY.md file with nothing in it,” he says. “I think the jury is still out on how effective this is going to be, but the hope is, it encourages people to start taking security more seriously, even in open-source projects.”