When GitHub unveiled its Security Alerts scanning feature last November, it was betting that if project owners knew which software components they were using had vulnerabilities, they would update them with patched versions.
GitHub was mostly right.
The scanning service compares the Common Vulnerabilities and Exposures (CVE) list against the dependency graphs of public GitHub repositories to find vulnerable components being used in projects. When GitHub initially launched the feature, which is currently limited to just RubyGems for Ruby and npm for JavaScript, the scanner found four million vulnerabilities in over 500,000 repositories. GitHub said that by Dec. 1, 450,000 vulnerabilities had been resolved, either by removing the dependency entirely or swapping out with a more recent, patched version. That's a little over 10 percent of the vulnerabilities addressed, right off the bat.
The alerts were displayed on the project's dependency graph and on the repository home pages. Project owners and repository administrators could see which components were problematic and either stop using it, or update to a newer version where the issue was resolved,
“In almost all cases, there’s a new, patched version of the library we can recommend in the alert,” GitHub wrote in its blog post.
Much of modern software development is less about writing code from scratch and more about writing code snippets to connect third-party libraries and open source frameworks. No matter how careful the developer was with the code, the application will still be vulnerable if the software components being pulled in to the project have issues. Developers need to check components regularly, and update them with newer versions as they come available.
That’s easier said than done, since developers don’t always know all the dependencies and sub-dependencies in their code. GitHub’s scanning feature takes out the guesswork because it takes care of the task automatically. Since that initial scan, GitHub said the rate of vulnerabilities resolved within seven days of receiving the alert has stayed around 30 percent. Additionally, 15 percent of alerts are dismissed within seven days.
That means nearly half of all alerts get some kind of response from the project owner within a week. Even taking into account the fact that the scanner is currently limited to just Ruby and JavaScript components, that's an impressive rate of response. It would be interesting to see what the numbers look like after GitHub extends the scanner to include Python code later this year.
One reason why developers may be responding so quickly, to remove or update dependencies, is because the alerts are part of the development workflow. There is no distinct process to run and no separate report to check. Vulnerabilities get fixed faster the earlier they are found in the development lifecycle. It's far easier to make changes to the components during active development, rather than when the code is in production and a change can break things.
GitHub's numbers also show the limitations to its scanner. Of the alerts that have not been resolved or dismissed, GitHub found the majority were in repositories that have not had a contribution in the last 90 days. That makes sense, since the project owner wouldn't have seen the alerts.
While some of these may be abandoned and not under active development, many of them are projects currently being used in production environments. Just because the project is not being actively maintained doesn't mean no one is using it. Those users won't know about the vulnerable components unless they look at the code themselves.
"GitHub security alerts are useful for developers who are actively working on software projects. This does not provide alerts for applications that are already in production, which is an important distinction," said Tim Mackey, technical evangelist for Black Duck by Synopsys.
Remember the downstream users, too. Anyone using the software other than the development team won't know about the issues. The software developer may make the changes in response to the alert, but if that update isn't broadly announced, all the teams using the project would never know they have to take action. And if the project owner doesn't take action at all, then the user is left exposed, and won't even know about the issues.
Security is a process, and we have to start somewhere. GitHub's scanning feature is a good first step and gets us closer to fixing flaws earlier in the software development process. Let's see other platforms that host code begin this kind of proactive scanning. Let's find ways to communicate the issues to downstream users and to developers who have forked the code. Let's expand code scanning to include other sources of vulnerability information, since CVE doesn't cover all software vulnerabilities.
Even GitHub acknowledged there is more to do in its blog post: "This is just the beginning -- we’ve got more ways to help you keep code safer on the way!"