GitHub Security Guide: How to Defend Your Organization and Repositories from Supply Chain Attacks

Software supply chain attacks are on the rise, and they’re aiming for your GitHub repository. Here’s how you can protect it by implementing GitHub’s security controls and best practices.

Thanks to the popularity of open-source libraries, third-party dependencies, and collaboration tools, code repositories are becoming more vulnerable to attack. Bad actors are finding new ways to infiltrate the software supply chain, inject malicious code, compromise dependencies, and even exfiltrate entire repositories – resulting in data breaches, system downtime, hefty costs, and reputational damage. 

Just look at the past few years. We’ve seen several high-profile supply chain attacks, including

• SolarWinds (2020) – in one of the biggest breaches to date, attackers gained access to thousands of public and private organizations, including the US government, via SolarWinds’ Orion IT monitoring system.
• GitHub (2024) – threat actors compromised multiple GitHub repositories by delivering malware within a popular Python package – an attack which, notably, affected Top, a platform that provides bots for Discord’s chat service. 

• Linux (2024) – after two years of lying undetected, a backdoor was discovered in the open-source compression library XZ, which may have given attackers access to infected Linux systems. 

Faced with the growing risk of code exfiltration and software supply chain attacks, enterprises must take steps to safeguard their repositories and assets, such as enforcing access controls to restrict permissions, multi-factor authentication (MFA), and encryption protocols to protect data, both in transit and at rest. 

By integrating security into every stage of the software development lifecycle and fostering awareness among developers, enterprises can mitigate supply chain risks and fortify their code repositories against potential threats.

GitHub 

GitHub is one of the most popular code management platforms today. It offers a Git repository and version control, and is widely used in the software development community for open-source and private projects.

GitHub allows developers to: 

• Collaborate on projects
• Track changes
• Host repositories
• Create branches for experimentation
• Submit pull requests for code review
• Manage issues 
• Continuously integrate code

GitHub Subscription Types

GitHub has three subscription types: Free, Team, and Enterprise. Each one has different security controls and management policies that can be applied to a GitHub organization, team (a GitHub group), or repository. 

GitHub Enterprise

GitHub Enterprise makes it easy to manage the code repositories of multiple organizations, which can all be given different access and security policies. The graphic below shows how this is structured:

Enterprise Security Controls

GitHub Enterprise offers unique security features that aren’t available in other subscription types, including:

Federated identities – customers can integrate their identity provider (IdP) with GitHub Enterprise, allowing their users to sign in to GitHub using single sign-on (SSO).

Centralized audit logs – Enterprise administrators can monitor their users’ activity using GitHub activity logs. 

Compliance reports – including SOC reports and Cloud Security Alliance CAIQ self-assessment.

How to configure GitHub Enterprise security controls

To open the Enterprise settings:

1. Click on your profile picture in the top-right-hand corner.
2. Navigate to Your Enterprises.
   
3. Find the enterprise you want to configure.
4. Click on Settings to the right of the enterprise name. 

To open the Organization settings:

1. Click on your profile picture in the top-right-hand corner.

2. Navigate to Your Organizations.

3. Find the enterprise you want to configure.

4. Click on Settings to the right of the organization name.

Enforce MFA authentication 

(Required licenses: Team and Enterprise)

GitHub supports MFA and allows every user to enroll a factor. However, it does not require MFA authentication by default. To protect users and code repositories, premium GitHub administrators can require their whole enterprise – or a specific organization – to authenticate via MFA. In this case, users who do not configure an MFA method are automatically removed from the organizational unit.

Note: In 2023, GitHub started requiring all users who contribute code to enroll in an MFA method by default. 

To require your users to sign in with MFA:

1. Navigate to Security > Authentication security in the enterprise/organization settings.
2. Select Require two-factor authentication for everyone in the <org name> organization.
3. Hit Save.

Enforce fine-grained personal access tokens

(Required licenses: Team and Enterprise)

GitHub allows programmatic access via public API and Git using personal access tokens. There are two types of GitHub access tokens:

1. Classic personal access token – works like an OAuth token, granting scope-based access to the entire organization/enterprise.

1. Fine-grained personal access token (in beta) – similar to the classic token but offers a more granular scope, allowing the creator to specify which repositories the token is allowed to interact with.

GitHub administrators can control which type of tokens are accepted at the organization/enterprise level. They can also require admins to approve access tokens before they can be used.

Here at Rezonate, we suggest you be as strict as possible when it comes to granting access tokens:

1. Opt for fine-grained tokens over classic tokens – they offer more granular control and security
2. Require admins to approve tokens 

To configure these suggestions:

1. In the enterprise/organization settings, navigate to Third-party access > Personal access tokens > Settings.
2. Then select:
   1. Allow access via fine-grained personal access tokens
   2. Require administrator approval
   3. Restrict access via personal access tokens (classic)
3. Hit Save.

Require SAML SSO authentication for GitHub Enterprise

(Required license: Enterprise)

SSO authentication reduces the risk of compromise since you’re not using a set of permanent GitHub credentials. SSO helps you reduce the unnecessary attack surface and overhead of credentials management.

Even though Enterprise clients enable Security Assertion Markup Language (SAML) SSO, they don’t necessarily enforce it. GitHub Enterprise admins can require their users (not including outside collaborators) to authenticate with SSO on the organization/enterprise level.

To require users to sign in with SAML SSO:

1. Navigate to Security > Authentication security in the enterprise/organization settings.
2. Under SAML Single Sign-On, after configuring an external IdP:
   1. Select Require SAML Authentication (if you’re configuring SAML SSO for the whole enterprise)
   2. Select Require SAML SSO authentication for all members of the <org name> organization (if you’re configuring SAML SSO for a single organization)
3. Hit Save.

Restrict base permissions for members

(Required licenses: Team and Enterprise)

By default, GitHub organization members have read permissions over all the public, private, and internal repositories in their organization. These base permissions can be excessive, which is why GitHub administrators are able to reset them.

Administrators can take the least privilege approach when it comes to code repositories by setting the base permission to No permission. This way, users will be able to pull code from public and internal repositories by default. If an employee needs more control over a specific repository, a repository admin can assign them extra privileges.

If a compromised organization/enterprise member has No permission set as their base permission, the attacker will only be allowed to read specific repositories instead of every repository in their scope.

To reset the base permission to No Permission:

1. Navigate to Access > Member privileges in the enterprise/organization settings.
2. In the base permissions section, set the permission to No permission.
3. Hit Save.

Invite outside collaborators

(Required licenses: Team and Enterprise)

Outside collaborators are users who are not part of your organization but can contribute code to your repositories. As an administrator, you cannot enforce security measures such as SSO and MFA for these users, which makes them a risk to your organization.

By default, GitHub allows administrators to invite outside collaborators to their repositories. If outside collaborators are not supposed to access certain (or any) repositories in your organization/enterprise, it’s best practice to disable this option. After doing so, only an organization/enterprise administrator can invite outsiders to repositories.

To revoke repository admins from inviting outsiders to their repositories:

1. Navigate to Access > Member privileges in the enterprise/organization settings.
2. In the outside collaborator’s section, deny repository admins from inviting outside collaborators.
3. Hit Save.

Restrict third-party OAuth application access

(Required licenses: Team and Enterprise)

When you turn on restrictions for third-party OAuth applications, organization members and outside collaborators can’t authorize OAuth apps to access organization resources. Instead, organization members must request owner approval for OAuth apps they’d like to use, which sends a notification to organization owners. If there are no restrictions over third-party OAuth applications, any member can permit access to organization resources.

To restrict third-party OAuth application access:

1. Navigate to Third-party access > OAuth application policy in the enterprise/organization settings.
2. If the policy is set to No restrictions, select Setup application access restrictions.
   
3. On the redirected page, select Restrict third-party application access.

Block commits containing secrets 

(Required licenses: Enterprise and Advanced Security)

Most vendors allow programmers to use their APIs to interact with their products. These APIs usually require an authentication method using API keys and secrets. Sometimes, however, these keys and secrets are embedded in code that could be exposed to unauthorized users. Many security breaches have started because sensitive API credentials with elevated privileges were mistakenly exposed by being uploaded to a public GitHub code repository.

To prevent secrets from leaking in this way, GitHub scans code pushed to public repositories and alerts when a secret is found. Enterprise admins with GitHub’s advanced security features can configure GitHub to block commits that contain secrets – even in private and internal repositories.

To configure secret scanning in your enterprise:

1. Navigate to Code Security and Analysis in the enterprise/organization settings.
2. Under Secret scanning, select Automatically enable for new public repositories.
3. Under Push protection, select Automatically enable for repositories added to secret scanning.

Summary

GitHub may be a household name, but that doesn’t mean you should take its default security controls for granted. Especially when, as an Enterprise subscriber, you’re responsible for multiple repos across different organizations – the more repos you have, the wider your attack surface is. 

Luckily, with a GitHub Enterprise subscription, you have access to a host of powerful security tools that can help you enforce strong authentication mechanisms, access controls, and permissions, and restrict third parties within your environment. By tweaking these controls accordingly, you can shut down the risk of code exfiltration and safeguard your critical resources.

Given the recent surge in supply chain attacks, it’s crucial to review your GitHub environment to detect and mitigate any vulnerabilities. At Rezonate, we offer a free risk assessment that can map out your current security posture across all your cloud, SaaS, and IdP applications – including GitHub – to identify weak spots and suggest remediations. 

To learn more about how the Rezonate platform can help boost your overall identity security posture, take a self guided tour.