GitHub’s new security scanner

A new service from GitHub is going to change how we build software. Again.

astract code [Thinkstock]

GitHub just announced a new service called “security alerts for vulnerable dependencies.” It’s not the catchiest name ever, but it’s a new service from GitHub that is going to change how we build software. Again.

The very short description of the service is GitHub is launching a service for public repositories that will look at your software dependencies, then alert you if there is a security vulnerability in one of your dependent components. This is a huge deal as before now it was very difficult to figure this out. The only options were rather expensive services or manual inspection. Neither is an option for most open source projects.

From reading about the service they’re going to leverage existing CVE data to populate their scanner with security details. It’s a bit poetic that MITRE just moved the CVE data to GitHub.

As with most news, there are already some security people complaining about this new GitHub effort. Everything from it won’t catch all flaws, there will be false positives, the CVE data is incomplete, basically the fact that this won’t be a perfect solution. These complaints are technically correct, but they’re not helpful and will thankfully be ignored.

The thing GitHub seems to understand that much of the security universe doesn’t understand is that change doesn’t happen overnight, and it’s never perfect the first time. Real change takes time and many iterations. This lack of understanding is no doubt one of the reasons our current security track record isn’t very good. Perfect and nothing are functionally the same thing in the end.

The data GitHub is using will be out of date, it will contain mistakes, and it will be incomplete. It doesn’t matter though. They will march this project forward, it will get better, and it’s going to make a huge difference in how software is built. Someday we will wonder how we built software without this level of insight into our projects.

Now this topic of understanding your dependencies isn’t new. I’ve been talking about it for years. I generally start the conversation about this topic by saying “open source won”. That used to be a controversial statement. It’s not anymore. In fact, I’ve not had anyone question me in a few years about it. It’s pretty clear open source won.

However, just because open source won doesn’t mean it gets some sort of free pass. The reason it won is because it’s very easy to incorporate open source into your own projects and get a huge boost in productivity. But how you include open source into your projects can bring a certain level of risk with it.

If you include open source software in a project that contains security vulnerabilities, now your project contains security vulnerabilities. It’s not uncommon for one open source component to contain copies of other components, and those components contain other copies and its dependencies all the way down. These multiple layers of dependencies can get out of hand quickly. You might think you are adding one thing, but you’re really adding seven.

The missing piece in the open source dependency story has been finding a way to understand what’s in a product or project and if those components need updating. In a perfect world everyone would update components with every build, but this is far from a perfect world. Updating your open source dependencies generally takes time and effort so we can’t update things constantly.

If you’re not updating your dependencies constantly, do you know if one of those dependencies has an unfixed security vulnerability? This problem has been getting more and more attention over the past few years as the success of open source has been noticed. With the new attention some hard questions have also arrived. The single biggest revolves around understanding your third-party dependencies.

It will be very interesting to watch how this service evolves at GitHub. No doubt it will have some problems as all new things do. The CVE data will have to be expanded, there are many open source components that don’t even know what a CVE ID is today. These are all problems we can solve though. The future of security will always be unknown and turbulent, but in this one instance I have high hopes that things will get better.

This article is published as part of the IDG Contributor Network. Want to Join?

New! Download the State of Cybercrime 2017 report