Three Ways DevOps Teams Can Step Up GitHub Security

Last week the team behind Git, a platform that powers millions of the world's developer code repositories--including those on the wildly popular GitHub hosted service--released a crucial security update meant to keep developer environments safe. The patch was made to fix a flaw in how Git handles submodule repository configuration during cloning. It's a dangerous hole that could give attackers the power to create malicious Git repositories and leverage them to run arbitrary code execution on target developer machines.

As leaders with Git and GitHub urge developers to update their client software, this is as good a time as any to revisit the important topic of GitHub security hygiene.

In its ten years of existence, GitHub has seen a meteoric rise in use among developers worldwide to store and share their code, both publicly and privately. Many forward-looking DevOps and Agile organizations depend upon GitHub as an important part of their continuous delivery toolchain and it is increasingly a mainstay for sharing open source software.

At the end of 2017, GitHub reported that its userbase had risen to 24 million developers and 1.5 million organizations around the world. GitHub hosts 67 million total repositories, with over 25 million of them active since September 2016. Of the Fortune 100, just under half of them use GitHub Enterprise.

It's an amazing tech adoption story that has thrown GitHub into such limelight that rumors last week surfaced claiming that Microsoft is mulling a multi-billion dollar acquisition of the firm. That kind of attention and such a mushrooming user base-particularly a privileged one like developers who frequently control valuable IP--also makes GitHub an increasingly juicy target for attackers.

The simple truth is that as developers have flocked to the platform, so too have the bad guys. This was made evidently clear last year with the Uber breach, which saw personally identifiable information for 57 million users exposed after attackers found Uber developer AWS credentials exposed on GitHub and used that to break into an AWS bucket with the goods.  The other thing made clear by that epic security fail is that many organizations are not bringing their "A" game when it comes to securing GitHub environments. Uber is far from an outlier.

Interestingly, most of the security problems highlighted in recent years have very little to do with vulnerabilities in the platform like the one updated last week. Instead, they've got everything to do with users failing to implement basic operational security practices. In the past year we've seen plenty of other signs beyond the Uber breach that offer evidence of this. We've highlighted a couple of these along with the lessons they offer for organizations looking to save themselves the pain of a GitHub-induced data breach.

Keep Configuration Top of Mind

Last June, consultants with Indian outsourcer Tata Consulting exposed sensitive source code and loads of other proprietary data of ten different financial institutions by publishing them on a public GitHub repository.  This episode shows how very easy it is to unleash sensitive assets, intellectual property and operational data publicly if your GitHub users don't take configuration seriously.

"Cloud services like GitHub offer enormous value for private companies and government organizations, who are in need of distributed, outsourced infrastructure to operate," says Mike Baukes, Co-CEO of UpGuard. "The problem with the cloud is that it’s fundamentally part of the internet, and unless the proper controls are in place, the data stored there is internet accessible."

GitHub tries to work very hard to make it easy to securely configure accounts and to offer advice on how to follow security best practices. This explainer blog is a good place to start for more information.

Don't Store Secrets

Unfortunately, GitHub is full of juicy secrets committed by harried developers who don't sanitize what goes into their repositories. These secrets run the gamut from plaintext credentials, authentication tokens, encryption keys and sometimes even personally identifiable information or business-essential data. Here are couple of war stories that show the kind of mistakes organizations are making: 

• Last November it was found that drone-maker DJI left the private key for its site's SSL certificate exposed on GitHub for up to four years, essentially opening up traffic to and from its website to any prying eyes who stumbled upon the key. 

• Global IT service provider DXC Technologies also suffered a big black eye last November when it came out that attackers were able to break into their AWS account to steal $64,000 worth of compute power by using a private AWS key that the DXC published to a public GitHub repository. 

• Even more embarrassing was a sensitive data exposure uncovered last September at Deloitte that basically came from the firm publishing corporate VPN passwords, user names and operational details on a public-facing GitHub repo.

The moral to the story here is that not only is configuration important, but so is limiting risk exposure in the first place. Developers should be making every effort to avoid storing secrets in their repos. This means staying away from hardcoded credentials, avoiding storage of any kind of private keys and never leaving plaintext credentials laying around.

Fortunately, there are a number of free tools available to organizations to help them start enforcing this common sense policy.

Here are a couple:

• Repo Supervisor: Scans files and checks for leaked secrets every time a pull request is made--can be run inside Docker containers.
• GitHound: A Git plugin to block sensitive data from being committed to a repository by sniffing them using PCRE regular expressions.
• Truffle Hog: A repository search tool used to dig up secrets that may have already been committed to repos.
• Gitrob: A command line search tool particularly good for looking for secrets and security snafus within custom GitHub Enterprise repos.

Turn on 2FA

There are a myriad of strong two-factor authentication options available for GitHub, including the free 2FA feature built directly into the platform. Unfortunately, too many organizations today don't turn 2FA on. In fact, it recently came out a few months ago that among the other massive missteps that Uber made in its breach, it also did not have any 2FA in front of its account.

GitHub can lead the proverbial horse to water--it provides plenty of informational materials to get started protecting accounts using 2FA--but it can't make you drink. It's up to organizations to read this kind of material and put it into practice.