Cybersecurity In-Depth: Feature articles on security strategy, latest trends, and people to know.

GitHub, used badly, can be a source of more vulnerabilities than successful collaborations. Here are ways to keep your development team from getting burned on GitHub.

(image by PixieMe, via Adobe Stock)

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."

 

About the Author(s)

Curtis Franklin, Principal Analyst, Omdia

Curtis Franklin Jr. is Principal Analyst at Omdia, focusing on enterprise security management. Previously, he was senior editor of Dark Reading, editor of Light Reading's Security Now, and executive editor, technology, at InformationWeek, where he was also executive producer of InformationWeek's online radio and podcast episodes

Curtis has been writing about technologies and products in computing and networking since the early 1980s. He has been on staff and contributed to technology-industry publications including BYTE, ComputerWorld, CEO, Enterprise Efficiency, ChannelWeb, Network Computing, InfoWorld, PCWorld, Dark Reading, and ITWorld.com on subjects ranging from mobile enterprise computing to enterprise security and wireless networking.

Curtis is the author of thousands of articles, the co-author of five books, and has been a frequent speaker at computer and networking industry conferences across North America and Europe. His most recent books, Cloud Computing: Technologies and Strategies of the Ubiquitous Data Center, and Securing the Cloud: Security Strategies for the Ubiquitous Data Center, with co-author Brian Chee, are published by Taylor and Francis.

When he's not writing, Curtis is a painter, photographer, cook, and multi-instrumentalist musician. He is active in running, amateur radio (KG4GWA), the MakerFX maker space in Orlando, FL, and is a certified Florida Master Naturalist.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights