How can an organization know if an open source project it builds with third-party libraries has known vulnerabilities? If the organization has its’ code on GitHub, there is an integrated alerting system, but understanding how to work with those alerts might not seem as obvious as you might think.
In a session at the Open Source Summit in San Diego, California on August 22, Gil Yehuda, senior director, open source and technology strategy at Verizon Media, outlined the security challenges and opportunities facing organizations that build open source projects on GitHub.
GitHub has become the defacto primary place to share code for many organizations engaged in open source, including Verizon Media. Yehuda explained that Verizon Media is a conglomerate, which is effectively made up of what had been Yahoo and AOL and includes many different online media properties. Across all those properties, Verizon Media has started over 330 open source projects, ranging from screwdriver, which is a continuous delivery technology, to Denali design, which is a user interface design language for open source projects.
The Open Source Program Office (OSPO), which Yehuda leads, is an effort to provide a programmatic approach to how Verizon Media handles open source. It’s an effort that involves legal compliance issues as well as ongoing project maintenance, which is where security comes into play.
“When we publish code and put it on GitHub and that code has a dependency on something and that something has a vulnerability, should we care?” Yehuda asked the audience. “The license says there is only limited warranty.”
Yehuda added that just because code is on GitHub, it doesn’t necessarily mean that the code does anything useful. That said, he noted that Verizon Media wants to build its’ open source program and establish a positive reputation, and that if someone decided to use their code, there is a certain confidence that that code isn’t garbage.
“We believe that OSPOs need to care about security in published code,” Yehuda emphasized.
With GitHub, getting notified of security vulnerabilities in project code is an integrated capability with the security alerts. The maintainer for a project will get an alert from GitHub whenever a code library is used that has known security vulnerabilities. Yehuda added that in many cases fixing the security issue is just a matter of upgrading to the latest version of a software library release.
However, a challenge that Yehuda pointed out, is not for individual projects, but rather for managing many projects at scale. He noted that it’s great that a project maintainer gets an alert and is diligent about fixing the issue, but what happens if the individual maintainer just ignores the alert and doesn't fix the issue?
To help solve that poblem, Verizon Media started a project called GitHub Security Alerts Workflow, which aims to help automate the reporting and alerting for security alerts at scale, in an integrated approach with the Jira issue tracking software platform. Yehuda said that the basic idea is to enable enterprise workflows for the security alerts.
With the workflow model, Yehuda suggested that if, for example, there was a project that was not being actively updated for security issues, the project could be labelled as such to warn users of potential risks.
“Maybe we need to change the project status to archive, and then change the read me on the project saying, this was once an awesome project, but our maintainers are not maintaining it now,” Yehuda argued. “If you want to be a maintainer and make it better let us know, but until such time that happens, buyer beware.”
The fact that an open source project can be identified by GitHub alerts as having a known vulnerability should not be seen as a weakness, but rather a strength, in Yehuda’s view. He noted that the real question isn’t whether open source is more or less secure than proprietary software.
“Open source has the potential to be more secure than closed source software because more people have access to the code, so you have more people who are able to fix it,” Yehuda said.