The Ultimate Manual to GitHub Security and Safety

With over 200+ million repositories across the globe, GitHub is undoubtedly the most popular open-source code management platform on the planet. But like any open-source system, GitHub security needs to be a top priority.

Whether you’re a developer or an organization using GitHub, this extensive guide will explain everything you need to know about GitHub security and safety best practices.

Why is GitHub Security and Safety So Important?

GitHub is trusted by over 73 million developers. 84% of Fortune 100 companies rely on GitHub as well. It’s used by enterprise organizations and hobbyist developers alike.

Developers worldwide rely on GitHub’s open-source code for various software development projects. But the re-use of open source code creates vulnerabilities between dependencies and repositories.

GitHub hosts public and private repositories, which allows remote developers to upload source code and share it with other contributors. That’s why so many organizations rely on GitHub for open-source collaborative development projects.

Public repositories on GitHub are just copies of private folders stored on a developer’s device. So a developer can work independently, then share the final code once it’s done.

This structure means that some developers unknowingly share private files and sensitive company data to a public repository on GitHub. So a GitHub user could accidentally share SSH keys embedded in code to a public, searchable database.

The use and continuous re-use of public code make it easier for hackers and those with malicious intent to infiltrate various systems. These vulnerabilities increase if something like SSH keys are copied into a public database. SSH keys are just one of the many types of files, code, and sensitive data that have been published on GitHub’s public repositories.

GitHub has built-in tools and features for security and safety. But these aren’t bulletproof, especially when it comes to human error. So if your organization is using GitHub, you need to have additional security and safety measures in place to ensure your developers aren’t unknowingly sharing sensitive data or using code with vulnerabilities.

How GitHub Security and Safety Works

Before we dive deep into GitHub security best practices, let’s first take a closer look at GitHub’s security offered out-of-the-box.

GitHub strives to constantly improve its security, audit, and compliance solutions. They have security measures in place to remove spam and eliminate abuse. This is accomplished through practices like incident response investments and anti-abuse initiatives.

Even though the platform is open-source, GitHub has its own security lab with a world-class research and development team. These security experts do their best to stay ahead of the curve and identify threats before they become a problem. The platform empowers the GitHub community to achieve top-of-the-line security via collaborative efforts.

GitHub’s product security engineering team begins with extensive development training. The team uses practices like threat modeling, security reviews, and threat testing to detect and prevent vulnerabilities in the development lifecycle.

GitHub also relies on the “red team” cybersecurity strategy. These internal team members play the role of a hacker or user with malicious intent. It’s their goal to hack the system and give the “blue team” a chance to stop the threat.

Here are some other noteworthy standouts of GitHub’s security and safety features:

• Bug Bounty Program — Anyone in the development community can get rewarded for CodeQL queries that detect and prevent open source vulnerabilities at scale. Some users have been rewarded bounties of $30,000 or more for assistance with critical vulnerabilities. It’s paid out more than $1.5+ million in bounties since launching back in 2014. This program really gives developers an incentive to look for threats and solutions in GitHub.
• Advanced Security License — Extra security features are available to GitHub users on an advanced security license. These features include code scanning, secret scanning, and dependency reviews. This can help you search for security vulnerabilities and coding errors while showing you the complete impact of changes to dependencies. These advanced features are also available for public repositories on GitHub.
• Data Privacy — GitHub is GDPR compliant through action, not certifications. The platform also offers AICPA SOC 1 and SOC 2 compliance reports. These include IAASB International Standards on Assurance Engagement, ISAE 3402, and ISAE 2000. You can also view a SOC 3 report for GitHub’s Enterprise Cloud system. GitHub is a member of the Cloud Security Alliance and supports FedRAMP LI-SaaS Authorization to Operate (ATO).

But no system is 100% secure. I want to quickly cover some real instances of GitHub security incidents to showcase where the platform can be vulnerable for your organization or development project:

Example #1: Optimus Scanner Malware

The GitHub Security Labs detected the Optimus Scanner Malware on 26 repositories in March of 2020. This malware targets open-source code and becomes active when a developer downloads an infected project from a public GitHub repository.

Once downloaded, the scanner deploys a RAT (remote access trojan) that infects the source code and files for the project. This essentially allows the malicious user to take control of the machine where the scanner has been installed.

Example #2: Unauthorized Crypto Mining

Justin Perdok, a security engineer at GitHub, discovered that cybercriminals were using GitHub repositories for unauthorized cryptocurrency mining. These hackers added malicious code to GitHub repositories.

This led to nearly 100 unauthorized crypto mining applications being unwillingly deployed to owner’s repositories.

Example #3: Corporate Secrets Leaked

More than two million corporate secrets were leaked on GitHub in a single year, according to a recent report. 12% of these leaks came from public repositories, and 85% came from the personal repositories of different developers.

Examples of the secrets found include:

• Google keys
• Development tools
• Data storage
• Cloud providers
• Private keys
• Social networks
• Collaboration tools
• Version control platforms
• Messaging systems
• CRMs
• Payment systems

Things like usernames, passwords, API keys, and other sensitive corporate information were accidentally exposed to the public on GitHub.

How to Get Started With GitHub Security and Safety

As you can see from the examples listed above, GitHub’s built-in security features alone aren’t enough to protect your organization from threats, breaches, and users with malicious intent. There are additional steps you must take into consideration if you want to apply GitHub security best practices to your process.

If you’re using GitHub to save time with open-source code or you’re using it for collaborative development, make sure you follow the tips below:

Never Store Credentials or Sensitive Data in Your Code or GitHub Files

If you run a quick search on GitHub, you’ll quickly see how big of a problem this is. So many developers and organizations have stored passwords in their repositories. I found more than 400,000+ commits for removed passwords.

That query doesn’t cover the users who weren’t using such an obvious commit message. It also doesn’t include developers who tried to remove their history.

To prevent yourself or your developers from accidentally storing passwords or credentials in GitHub code, you can use tools like pre-commit Git Hook or Git-secrets. These tools analyze your code and search for sensitive data and passwords before pushing information into a GitHub repository. If the tool finds something that looks like a password or sensitive file, the commits will be rejected.

This process may slow down your commit pushes, but it’s worth the extra step to ensure nothing sensitive is being pushed into GitHub.

Let’s say you’re searching a repository to see if you’ve exposed sensitive information. Now what?

First and foremost, assume that the information is already in the hands of a hacker or someone with malicious intent. So you need to quickly invalidate all of the passwords or tokens that were made public. Once you remove the sensitive data from your repositories, you also need to clear your history and changelogs.

Strengthen Access Controls

Having a proper access control policy is one of the best ways to beef up GitHub security.

For starters, you should implement a least privilege model. This means that each user is only granted access to files, data, and permissions that are strictly necessary for their position, job, or assignment. You need to consider access control policies for your in-house team, as well as any external contributors or collaborators you’re working with.

Here are some tips for you to consider as you’re going through this process:

• Make sure you require two-factor authentication for each contributor account.
• Don’t let anyone share a GitHub account or password.
• Secure access to any computers or devices with source code.
• Make sure repository admins are only giving contributors access to data that they need to do their job.
• Manually revoke access to all GitHub accounts that are no longer part of your project or team.
• Periodically review the access right to all GitHub projects.
• Rotate SSH keys and personal access tokens.

By tightening up your access controls, you can benefit from enhanced security using GitHub by reducing your biggest vulnerability—human error. Lots of hackers or people with malicious intent will target weak users as a way to breach the system. But if each user has limited access, it ultimately limits your exposure.

Validate All GitHub Applications

If you browse through the GitHub marketplace, you’ll find hundreds of applications that come from third-party organizations and developers. Before you blindly add one of these apps to your GitHub repository, you need to conduct some due diligence to ensure it’s safe.

Here are some best practices to keep in mind when you’re using a third-party party application:

• Don’t allow applications to have more access rights than required.
• Investigate why an application requires the access levels it’s requesting.
• Assess the potential damage that might be caused by granting an application a certain level of access.
• Verify the legitimacy of the author or organization that created the application.

Remember, you’re only as secure as the weakest link in your fence. Similar to users and contributors, an application with weak security can add vulnerabilities to your sensitive data. This means that if an application is hacked or breached, a hacker can access the code that you’ve permitted the application to access.

Disable Forking and Visibility Changes

Forking is a common technique used on GitHub. The practice allows developers to copy repositories without implicating the original code. This is great for sandboxing and experiments, but it makes it difficult to track where your sensitive data and credentials are going.

For example, you might have a private repository that can go public if forking is enabled. This increases each time a fork occurs, creating an exponential chain of potential security breaches.

You disable forking by going to the Member Privileges menu of your organizational Settings. Then uncheck the option labeled Repository Forking.

It’s also in your best interest to disable visibility changes. A developer who doesn’t have security best practices in mind may accidentally change a repository’s visibility. This simple and seemingly innocent mistake can make your repositories public or grant access to users in your organization that don’t need the information.

If people have the ability to change the visibility settings of a repository, it increases your potential points of failure. This is obviously not good if your repositories have sensitive data.

You should change these settings to only allow admins or organizational owners to change visibility settings. The number of users who can complete this action should be extremely limited.

Limit GitHub Access to Allowed IPs

It’s difficult for larger organizations to keep track of everyone at all times. So an easy way to prevent unwanted access to your GitHub repositories is by creating access controls via IP addresses.

This only allows on-site users to access the organization’s source code and repositories. Users who have access to your company’s static remote IP will also have access here.

GitHub allows you to manage and restrict whitelist IP addresses through your Organizational Security settings. Admins can configure a specific list of IP addresses or ranges that can access the system.

These best practices give you more control over the environment that contributors are using while working on your code. You won’t have to worry about them working from an unsecured device or network that’s not part of your whitelist IP settings.