Popular cloud service GitHub is a public code repository for millions of open source projects.
For example, you can get Microsoft’s JavaScript engine, ChakraCore (yes, it’s open source), from GitHub; you can also find Google’s V8 JavaScript engine, the macOS HomeBrew project, and plenty more.
Few open source projects stand all on their own – most of them build on other open source components, either by packaging them in, or relying on you to install them at the same time.
And that’s a bit of a security nightmare, because your vulnerability risk isn’t just the sum of all the unfixed security bugs in the code of the project you’re installing.
Your risk also includes the recursive sum of all the security bugs in all the sub-projects on which your chosen software depends.
If the maintainers of your selected project don’t keep an eye on the security problems in every sub-project on which they rely (and they may have their hands full keeping on top of the security status of their own code), then you could be in trouble.
So, GitHub has announced that it will be scanning its millions of code repositories looking for projects that rely on components that need a security update…
…and sending the maintainers of affected projects a friendly reminder that they need to take action:
We found potential security vulnerabilities in your dependencies.
Some of the dependencies defined in your Gemfile [the way that Ruby programs list the components they rely upon] have known security vulnerabilities and should be updated.
We think this is a great idea, because it puts pressure on developers to “do the right thing” early on in the code distribution process.
Public GitHub repositories will be scanned by default.
If you use GitHub as a cloud service for your own private code projects, you have to opt in to the vulnerability scanning, but we can’t imagine why anyone wouldn’t bother, unless perhaps they are maintaining a known-buggy configuration for testing purposes.
At the moment, these automatic “you ought to do something” warnings only apply to dependencies written in Ruby or JavaScript (technically, Ruby Gems or NPM packages), and only to vulnerabilities that have been assigned an official CVE number.
But it’s a great start, and we’re hoping both that GitHub will extend the range of source code projects it validates in its scanning, and that other source code repositories will follow suit.
Of course, knowing about a security hole is only the beginning, as Target found out four years ago when it ignored warnings that could have headed off its massive 2013 data breach during which more than 40,000,000 credit cards were skimmed in the Thanksgiving-to-Christmas retail season.
Patch early, patch often!
GitHubGuy
That last sentence is my favorite saying
David Pottage
This sounds like a very interesting development, though like many it is the first step in a long road. For now it only covers Java and JavaScript (The two most popular languages on GitHub according to githut.info), so many other languages to go. Secondly it only covers libraries with known security bugs, not those with other sorts of bugs, or libraries that encourage insecure programming without actually containing bugs themselves. Hopefuly Github will find a way to work down the list of languages and broaden the checks they apply.
Paul Ducklin
From GitHub’s own article on this (click image above to go there):
“GitHub tracks public vulnerabilities in Ruby gems and NPM packages on MITRE’s Common Vulnerabilities and Exposures (CVE) List.”
No Java yet, apparently.
Mahhn
How are they doing the scanning? With Mayhem or one of it’s super computer sisters? and if so, will it auto patch, offer recommendations, or just alert?
Paul Ducklin
For what we know so far, click on the image in the article. It does offer recommendations, as you can see from the image, but it’s Ruby and JavaScript modules only so far, and only when updates include a fix that was “awarded” a CVE.