GitHub Security Best Practices Your Team Should Be Following

Configuring security in GitHub correctly can offer strong protection against breaches related to application vulnerabilities. The platform comes with specific settings and built-in security features that can be enabled to protect users and organizations. Github security risks are rarely the result of missing functionality (which probably exists in a Github advanced security feature) or a lack of configurability in the settings. As long as you train your team to use these features properly, you can leverage powerful capabilities to improve GitHub safety and beef up security measures.

GitHub Docs provides helpful tips throughout their documentation to help you protect your Github deployment. 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

Failing to properly implement GitHub security can expose your repositories to significant risk. This recent GitHub data breach is a perfect example of why you should consider security and GitHub to be intertwined., and why tools like GitHub security scanning should be top priorities when using the platform.

This particular breach exposed data from dozens of private code repositories to an attacker who was able to download the data. An attack like this can cause extensive damage to an organization that is storing critical and sensitive information inside their GitHub repositories.

Making an effort to understand the risks associated with GitHub and putting plans in place to remediate those risks will help you to secure your GitHub deployment and keep your code repositories and data safe.

While the importance of creating robust and digitally secure code is widely understood, that doesn’t mean that security isn’t treated as a secondary consideration too often, when organizations should be focused on implementing a methodical approach to securing their SDLC.

In particular, organizations that take a continuous integration/continuous deployment (CI/CD) approach to software development need to implement an always-on approach to security. That means application security should be a priority at EVERY phase of the development process.

Studies have shown that a combination of mistakes by developers and security breaches have exposed millions of data points and an extensive amount of valuable, sensitive information. And these are frequently the byproduct of easily prevented security oversights.

Top 5 GitHub Security Best Practices to Implement Now

Successful attacks to infiltrate and steal 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 for securing your GitHub deployment to help secure your SDCL and critical assets.

The following recommended best practices can apply to organizations using both GitHub Enterprise Server and GitHub Cloud.

1. Restrict & Control Access

Most organizations have some measures in place for tracking, managing, and restricting access for users. But if those controls to secure access aren’t adequately implemented and maintained, it significantly increases risk for security breaches to happen.

Lax Git security like unrestricted or unsecured GitHub access is one of the easiest ways to enable a security breach. Fortunately, it can also be quickly addressed with a few easy to implement GitHub security measures.

There are many ways to improve your GitHub security. Here are a few tips for reducing GitHub security risks:

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 access to a series of branch protection rules that make sure any new code changes are done through a controlled merge process, allowing you to enforce code review and perform other security tests. This is particularly critical with larger software development teams follow CI/CD processes where a lot of code is created and deployed as quickly as possible.

Branch protection is a git security measure that can help you lower your risk exposure to many internal threats and can 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 make sure that you aren’t releasing code with critical vulnerabilities, a best practice approach is to establish and employ security testing guardrails as a routine part of the SDLC. You should also 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.Finding and eliminating malicious code earlier in the SDLC, using a shift left philosophy, may be the most effective way to secure your applications.

• Imported code

  Before you import any projects or large chunks of existing code, it’s imperative that you complete a full audit of the new code. 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. This is a critical step in ensuring that you are building application security best practices into your SDLC processes.

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

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

  Static Application Security Testing (SAST) can automatically source code, byte code and binaries to look for security flaws, which could potentially turn out to be critical vulnerabilities. This is a critical step in ensuring that you are building application security best practices into your SDLC processes.

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

  Software Composition Analysis (SCA) detects 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. It’s critical to analyze your 3rd party code to understand when you are introducing unnecessary risk into your SDLC.

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. This software bill of materials is another resource providing relevant context that will help you quickly understand how application security risk is being introduced into your code.

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. And this is unfortunately common in CI/CD pipelines as developers take shortcuts to iterate faster and meet commit deadlines, often at the expense of maintain good application security hygiene.

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. The combination of code sprawl and persistence means that secrets in code can be exploited long after developers have moved on from a particular code project.

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. Code traceability is a valuable capability to expedite this process.

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. Developers often fork code to accelerate software development by not recreating code that already exists.

One of the problems with forked repositories is that they 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. And as more forks are created, securing the code becomes more difficult, particularly when the original has a critical application vulnerability.

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. If possible, you should implement a solution that incorporates code traceability to identify where a fork originated and where additional forks may have ended up.

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. Even if they do consider application security to be a priority, with the pressure to innovate quickly, CI/CD processes often don’t leave developers with enough time to dedicate to securing their code. But 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. Legit integrates quickly with your deployments to start providing immediate visibility and insights to your GitHub security efforts.

Boost Your GitHub Security Today.