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 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.
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!"