How to Stay Secure on GitHub

Open source software is a fact of life for enterprise software developers, and GitHub is a fact of life for many open source software projects. The development platform and code repository has become the de facto home for projects ranging from enterprise applications to malware. The question for many security teams is how to make GitHub a safe place for their organization to get -- and store -- code.

There are a variety of different suggestions for best practices on GitHub -- suggestions that include both the obvious and the subtle.

And it's important to remember that "GitHub" isn't a monolithic thing. Much like content management system WordPress, there's the publicly available and accessible repository used by countless individuals and open source projects, there's the hosted private repository used by thousands of organizations with distributed software development group, and there's "Git," the code repository software that can be self-hosted by organizations that aren't looking for a SaaS solution.

The issues and solutions we found are applicable to all of these, but especially to the organizations that are using the public or hosted versions, GitHub.

Just Don't
Usernames, passwords, and other credentials should never, ever be included in code or comments. This is true whether you're talking about GitHub, a local code repository, or any other place code is stored. As a matter of security, credentials just should not be hard-coded into applications.

"Organizations that use public repositories need to be very careful about the information that gets made public," says Brian Jack, CISO at KnowBe4. "Passwords, access tokens, and other sensitive information have been found many times to be included in public source repositories."

He also points out the need for an approval process for any information posted publicly, whether the posting is to social media or a code repository.

Who's There?
With so many open source projects hosted on GitHub, many people assume that all access to projects and code should be completely open. This may be fine philosophy, but, according to many security experts, it's poor security practice.

"The lack of role-based access control [RBAC] enforcement is one of the most common issues organizations overlook," says Brendan O'Connor, CEO of AppOmni.

As with other with other critical software-as-a-service (SaaS) applications, "it's important that all access to code repositories in GitHub adhere to the principle of least privilege," O'Connor says. "Organizations and security teams must ensure that the access to repositories is properly managed by using the 'Team' construct in GitHub, and that individual users are assigned only to the Teams they support or work for. This ensures that they only have access to the code repositories they need."

In Open Source Projects, There's Safety in Numbers
There can be a significant difference in security between projects supported by one person and those that are the product of large communities.

"It is important to regularly check if the GitHub account allows many people to contribute content or if it is a single, well-known entity that owns it," says Mounir Hahad, head of Juniper Threat Labs at Juniper Networks. "If it's the former, never blindly trust an update and download a patch or a new revision without performing code review. It's tedious and complex but a mandatory step and the price to pay for getting access to open-source software."

Bryce Larson, senior SRE at SaltStack, agrees.

"One of the ways open source software stays secure is by having more eyes on the code," he explains. "If you have a project that only has one developer, the chance that one developer realizes that a piece of code is insecure is much lower than if there are many eyes all on that same code. This is one of the reasons why code reviews are a common practice. It gives a greater chance of finding problematic code earlier."

Developers should treat the code they are taking from Github the same as any code they'd use in their production systems. "It should be tested thoroughly for security vulnerabilities," says Timothy Chiu, vice president of marketing at K2 Cyber Security.

Adds KnowBe4'S Jack: "Organizations must treat these repositories in the same way that they would perform development in house; the code should be reviewed, scanned, tested, and no changes should be allowed to happen unless the code review process can happen." 

Review Your Health Regularly
If your approach to security in GitHub is to simply make scheduled reviews of security, you will fail at keeping your projects secure, O'Connor says.

"As with many business-critical SaaS applications today, GitHub is a living system. Its configuration constantly changes and does so rapidly," he says. "This creates a challenge for the organization. The risk of posture and configuration drift over time is almost a certainty as users change roles, new collaborations and integrations between teams take shape, and new repositories are created."

The goal -- by constantly being aware of both internal and external threats -- is to minimize the number of threats that make it into production code. After all, explains Alex Uberlis, partner at the Blackstone Law Group, "Data, like toothpaste, is nearly impossible to return to its container once out in the open."