The December 2022 issue of IEEE Spectrum is here!

Close bar

GitHub Releases New Tools to Report Vulnerabilities

The new features came out the same day as a study that found many open-source projects lack a clear way to report security problems

3 min read
Atul Prakash, Professor of Electrical Engineering and Computer Science, works on code from a project giving Github users an infrastructure to report vulnerabilities.
Atul Prakash, a professor of electrical engineering and computer science at the University of Michigan, works on code for a research project into how GitHub users report security vulnerabilities.
Photo: Joseph Xu/Michigan Engineering

For most software developers, importing code from third-party libraries is an easy way to add new functionalities to a program without building those features from scratch. But relying on open-source libraries can be risky, as hackers often target security vulnerabilities within them.

Given all this, it’s important for users of any library to be able to report potential security issues to the project’s owners, so such problems can be fixed before they’re exploited. But until recently, many projects on the online repository GitHub lacked a clear way for users to submit security reports.

“I think reporting is the first step needed,” says University of Waterloo assistant professor Meiyappan Nagappan. But, adds University of Michigan professor Atul Prakash, “if the reporting process isn't simple and straightforward, that can discourage or delay security reporting. And that can have consequences.”

While working on another project in 2018, Nagappan and his team found it difficult to report a vulnerable version of Apache Struts, the open-source library hackers exploited to breach Equifax in 2017. They tried informing other GitHub projects with the same dependency through a combination of emailing project owners, opening issues, and submitting pull requests.

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 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.”

[shortcode ieee-pullquote quote=""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."" float="left" expand=1]

GitHub’s security policy involves the same 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 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.”

The Conversation (0)

Why Functional Programming Should Be the Future of Software Development

It’s hard to learn, but your code will produce fewer nasty surprises

11 min read
A plate of spaghetti made from code
Shira Inbar

You’d expectthe longest and most costly phase in the lifecycle of a software product to be the initial development of the system, when all those great features are first imagined and then created. In fact, the hardest part comes later, during the maintenance phase. That’s when programmers pay the price for the shortcuts they took during development.

So why did they take shortcuts? Maybe they didn’t realize that they were cutting any corners. Only when their code was deployed and exercised by a lot of users did its hidden flaws come to light. And maybe the developers were rushed. Time-to-market pressures would almost guarantee that their software will contain more bugs than it would otherwise.

Keep Reading ↓Show less