6 min read

GitHub Security Best Practices Your Team Should Be Following

Featured Image

GitHub can be configured to be fairly robust against security breaches. It has various security features and settings that enhance the safety of its users and organizations. Git security risks aren’t usually due to a lack of tools or settings. Instead, it comes down to ensuring your team knows how to use these powerful capabilities to beef up security measures.

GitHub Docs provides helpful tips throughout their documentation. The GitHub Security Lab’s research blog is another excellent place to go to stay on top of all the latest security trends, features, and threats.

This article will explain why security and GitHub should go hand in hand and describes a few best practices we believe any organization using GitHub should employ to reduce GitHub security risks.

Here’s Why You Should Amp Up Your GitHub Security Measures

Neglecting aspects of Git security can lead to serious problems. This recent GitHub data breach is a perfect example of why security should be a top priority when using this service.

This breach allowed an unknown attacker to download data from dozens of private code repositories. Such an attack can cause grave damage to an organization with critical and sensitive information inside their repositories.

By understanding the risks involved in using GitHub and taking steps to mitigate those risks, you can keep your account and data safe.

Most people acknowledge the importance of creating robust and digitally secure code, but many times security considerations can be more of an afterthought rather than a methodical and secure SDLC approach.

However, organizations with digital business models necessitates an always-on approach to security. That means you should be considering it at EVERY phase of the development process.

Studies have shown that unaware developers and security breaches have leaked hundreds of thousands of data points and keys for valuable, sensitive information – often as the result of preventable security oversights.

Top 5 GitHub Security Best Practices to Implement Now

Attacking the source code within the SDLC can occur from various GitHub misconfigurations. Organizations, repositories, and users' settings are not secured by default. Below we provide the top five recommendations to help you make sure you’re on the right path.

These best practices are relevant for both GitHub Enterprise Server and GitHub Cloud organizations.

1. Restrict & Control Access

We often get lackadaisical about keeping track of, managing, and restricting access for users. But it doesn’t take much effort for security breaches to happen when access isn’t properly protected.

Unrestricted or unsecured GitHub access is one of the easiest ways to invite a security breach.

GitHub Tips for controlling and securing access:

  • Enforce 2-factor authentication on an organizational level

  • For GitHub Enterprise, use an external authentication provider, such as SAML SSO, LDAP, or CAS

  • Secure all endpoint devices (laptops/mobile/tablets, etc.) with access to the source code

  • Limit the number of repository admins

  • Adhere to the least privilege principle - restrict access for contributors to the data that applies to their task needs and nothing more

  • Revoke access for users that no longer exist

  • Rotate SSH keys and Personal Access Tokens

  • Limit access to allowed IP addresses

2. Protect Your Code Branches

GitHub provides a set of branch protection rules which ensures new code changes must go through a controlled merge process and allows enforcement of code review and other security tests.

Branch protection is a git security measure that will help you reduce the risk of internal threats and prevent unwanted code from being pushed into production. It is one of the most important security considerations.

It is recommended to enable branch protection for your default main branch. Once enabled, you’ll be able to enforce the following GitHub repository best practices:

  • Prevent force pushes and deletions

  • Require a pull request before merging

    • Define a minimal number of required approvals before merging

    • Dismiss stale pull request approvals when new commits are pushed

    • Require review from Code Owners (defined in a dedicated file inside the repository)

    • Restrict who can dismiss pull request reviews

  • Require a branch to be up to date and pass predefined status checks before merging

  • Require conversation resolution before merging

  • Require signed commits

  • Require deployments to succeed before merging

  • Enforce restrictions for administrators as well

3. Scan for vulnerabilities with Security Control Tools

To ensure your code doesn’t contain vulnerabilities, it is highly recommended to employ security testing guardrails as part of the SDLC. Establish code audits for both new and imported code:

  • New code

    Complete audit/review to ensure that malicious code doesn’t get officially merged into the branch. This also helps detect code smell and identify future vulnerabilities down the road.

  • Imported code

    Before you import any projects or large chunks of existing code, it’s imperative that you complete a full audit. While this might seem time-consuming or tedious at first, it can save you time, money, and headaches down the road. This is especially important when you’re importing code from a closed-source repository.

The two main types of security controls required for this task are:

  • SAST (e.g., SonarQube, Veracode)

    Automatically scan your code and look for security flaws, which could potentially turn out to be critical vulnerabilities.

  • SCA (e.g., Snyk, WhiteSource)

    Detect vulnerabilities in dependencies. 3rd party packages used by your code might contain security holes. Once a malicious actor manages to exploit such a package, they can use it to create a software supply chain attack on your organization.

To ensure you are covered continuously, define dedicated Pull-Request checks for these tools to prevent developers from introducing new vulnerabilities into production. As part of their GitHub Advanced Security feature, GitHub provides an internal dependencies vulnerabilities scanner - Dependabot - which can also suggest an automatic PR to resolve the detected vulnerability. You can also use an SBOM generating tool to catalog internal dependencies.

4. Keep Secrets and PII Away from Code

One of the most preventative security measures you can put in place is constantly making sure sensitive data doesn’t find its way into your files & GitHub history. Hardcoded secrets like passwords, API keys, and tokens in git repos will provide anyone with read access to those repos with all the power they need to take over an organization's critical assets. This becomes significantly more dangerous for public repos – any GitHub user will be able to find the sensitive data.

A common mistake, which usually stems from naïve efforts to improve developer convenience, is to place credentials to CI/CD assets in the code that manages the production pipeline. In most modern systems, this code resides inside the git repo. Even if deleted at a certain point in time, it will remain in the git history and allow a determined adversary to access those CI/CD assets, thereby initiating a supply chain attack.

It is recommended to use secret detection tools as part of the development process. The most secure way is a git pre-commit hook, which prevents the secret from entering the git history.

With GitHub Enterprise Server, this can be enforced for all users by creating a pre-receive hook script. When this option is not available, use a PR check to prevent secrets from entering your main branch.

However, in such a case, remember that it already exists inside the developer branch’s git history.

If a secret found its way to the git history, it should be considered compromised, and thus, the best thing to do is revoke that secret. Additionally, monitor access to the resources that the exposed secret could have given an attacker access to and investigate any suspicious behavior.

5. Beware of Forks

A fork is a copy of an existing repository in which the new owner disconnects the codebase from previous committers. It is commonly used when a developer wants to contribute to an open-source project or when an organization wants to allow the same core project to be developed in a few different directions.

Forked repositories might become a source of uncontrollable sensitive data leaks and may harm code repository security. Suppose, for instance, a secret or critical IP code resides in a repo. In that case, this sensitive data will travel on all the repos that were subsequently forked from it, and it may become much worse if the visibility of the forked repos is changed from private to public.

On GitHub, public repos are forkable by definition, but private repos' forkability can be configured, and that’s where problems can arise. Although GitHub does a good job in protecting against fork issues, it is recommended to disallow forking on the organization level through the member privileges of the org settings, or, in case forking should be allowed for some specific repos, you should make sure the rest of them are configured not to allow forking. Moreover, keep track of forking events through the organization’s audit log and make sure any created fork is legitimate.

Let the Experts Help You Implement These GitHub Security Best Practices

Git security shouldn’t be underestimated. There is a plethora of powerful features at your disposal to ensure that things stay locked down. It’s unfortunate, but many teams consider security measures more of an afterthought because of other business pressures. With the increasing trend of security breaches, you should begin preparing for just about any type of security breach including those against GitHub. There’s never been a better time than now to start beefing up your GitHub security.

The list above provides a few easy best practices that you can put into place yourself. There’s much more that can be done to bring your organization’s GitHub safety to its maximum level. Legit Security has developed a platform that automatically alerts you when any deviation from GitHub best practices is detected, whether you use GitHub Cloud or GitHub Enterprise Server, or many other types of SCM tools.

Boost Your GitHub Security Today.

Related Blogs

Novel Pipeline Vulnerability Discovered; Rust  Found Vulnerable

The Legit Security Research Team discovered a new class of software supply chain vulnerabilities that leverages artifact poisoning and attacks the...

Read More

Top Software Supply Chain Security Solution Approaches: Pros and Cons

What are different solution approaches to software supply chain security and what are the Pros and Cons for your organization? What is the modern...

Read More

1 min read

Critical and Time Sensitive OpenSSL Vulnerability - The Race Between Attackers and Defenders

Update: On November 1st the OpenSSL project maintainers released their fix for the vulnerabilities. There were two vulnerabilities discovered. After...

Read More