STE WILLIAMS

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!

Follow @NakedSecurity
Follow @duckblog

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/z6aAOwqDiCc/