10 Best Practices for Securing GitHub Enterprise SaaS

GitHub plays a critical role for many software teams, as it’s one of the most popular places for organizations to store and manage their code.

GitHub organizations and repositories can be configured in many ways. Settings at the organization, repository, and user levels impact your overall security posture.

Our security professionals at Blink created this list of best practices to reference so you can make sure that your organization has a secure GitHub configuration. If you want to maintain compliance with security standards like this over time, you can enforce each of these policies with automated workflows in Blink.

10 SaaS Security Best Practices for GitHub

To preface these recommendations, it’s important to note that every organization is different with unique use cases. So, some of these items may not be as applicable. Consider whether your organization should be exempt from each of these for any reason before implementing them.

1. All repositories should have branch protection enabled on the main branch.

Branch protection rules are a security policy set within Github that enable you to restrict how collaborators can push changes to a branch in your repository.

For example, branch protection rules prevent collaborators from being able to delete the protected branch or force push to it.

While these protections do not apply to repository admins, when enabled, they can help reduce the risk of accidents or damage to your branches. We recommend enabling this policy on all main branches.

2. All repositories should prohibit force push for non-admins.

When you have enabled branch protection rules, force pushes are prohibited by default for non-admins. This setting can be updated to allow force pushes on protected branches.

Force pushes can cause issues because they can overwrite commits that collaborators are referencing, cause merge conflicts, and corrupt pull requests.

You should review your branch protection settings to ensure that force push is not allowed by non-admin members.

3. All repositories should require pull requests to have at least 1 approval for protected branches.

Peer code reviews are a critical quality assurance measure. You should require that all pull requests have been reviewed and approved before being merged. Using branch protection rules, you can specify that protected branches require at least one approval.

You can read the requirement options here so you can ensure it fits your team’s way of working.

In Blink, you can enforce this rule with an automated workflow that opens a Jira ticket if no approvers were required on a pull request to the main branch.

4. All installed GitHub apps should appear in a maintained allowlist.

When you are connecting 3rd-party apps to your GitHub organization, you are granting permissions to those apps and introducing some level of security risk.

An approval process for adding new apps to your GitHub organization enables your security team to quickly review whether the app is reputable or requests excessive permissions.

Automation platforms like Blink allow you to create streamlined approval flows by exposing self-service apps to developers.

For example, if a team member wants to install a new app to your GitHub organization, they can submit a form to kick off a security review and get updated on the outcome.

If the app is approved, then automated workflow steps can automatically add that app to a list of allowed applications ( "Github <Org Name> app allowlist” ).

You can also set up a daily automation to check that no apps have been installed in your GitHub organization that have not been reviewed and are not in your allowlist. If a rogue app is found, the automation will open a Jira ticket with the necessary context.

5. Anyone given admin permissions in GitHub admins should also appear in a maintained allowlist.

You can take a similar allowlist approach for admin permissions. If there is a security incident, you want to make sure that no one has GitHub admin permissions that shouldn’t have them. You may also want to take different mitigation steps depending on if they are an admin.

With an approval flow and a maintained list of allowed users ("Github <Org Name> user allowlist”), you can easily check to make sure that no one has escalated permissions to admin level without being noticed.

6. Organization members should not be allowed to create public repositories.

Public repositories are useful for showcasing personal work or fostering open source or collaborative projects, but they should not contain any proprietary code. If someone in your GitHub organization creates a public repository, intentional or not, it could introduce a security risk of proprietary code being exposed.

You should restrict organization members from being allowed to create public repositories. If there is a specific use case where it makes sense to have a new public repository created, it should be communicated to GitHub admins to configure.

You can enforce this best practice with an automated workflow in Blink. For example, this workflow creates a Jira ticket if the current GitHub policy allows organization members to create public repositories.

7. Organization members should not be allowed to create repositories.

You may also want to restrict organization members from creating any repositories. By reserving this action to only GitHub admins, you can ensure that repositories are set up with your organization’s standard settings.

8. Organization members should not be allowed to fork private repositories.

You may also want to prevent organization members from being able to fork private repositories. Forking creates a new repository with the same code and visibility settings as the original. This process introduces new risks, like unreviewed code changes, malicious code run by bad actors during a breach, and hard-to-detect data theft.

9. All organization users should have MFA enabled.

Multi-factor authentication ensures that there are multiple verification steps when users sign in. If a bad actor has obtained a GitHub user’s credentials, MFA could be what prevents them from accessing your GitHub organization.

You can run a daily check using a Blink automation to ensure that every member of your GitHub organization has enabled MFA on their account.

10. Secret scanning should be enabled for all existing and new repositories.

Secret scanning is a GitHub feature that detects whether tokens or private keys are present in any branches in your repositories. These secrets could be used inappropriately by anyone with read-access to the repository. 

If enabled, secret scanning will create an alert in the Security tab of the repository and send an email to repo admins and organization owners.

You can use an automation in Blink to check that secret scanning is enabled for all of your repositories so you know this detection is active. By running this automation daily, you can ensure that this setting is universal even as new repositories are created.

Ensuring Your GitHub Security Posture Stays Strong with Blink

All of these security recommendations can be configured once, but what happens as your organization evolves? Over time, acquisitions, new projects, or changing team structures could impact the shape and consistency of your GitHub organization.

With Blink, you can run automations on a daily schedule to check your GitHub organization and repository settings to ensure they stay aligned with best practices.

There are certainly other security best practices for GitHub that we didn’t have time to cover, but it’s easy to add automations for custom policies in Blink. If your organization has aligned on a set of basic security policies for GitHub, automation will play an important role in validating compliance. We have built a full pack of automations for GitHub that can help you quickly secure your repositories and reduce your risk.

To get started enforcing these GitHub security practices, you can schedule a demo with Blink experts today.