Checklist: How to secure GitHub
The definitive guide on how to clean up security in GitHub
Today’s internet-centric world feels a lot like the wild west. Constant threats everywhere and dangers lurking around every corner for both individuals and modern businesses. In our Wrangling in the Wild West series, we explore how IT and security teams can combat lawlessness and chaos by cleaning up a variety of security and privacy risks across the SaaS tools that they’re responsible for.
GitHub is a leading platform to store, version, and collaborate on software and code powering many companies. When precious intellectual property living in GitHub is often the bread and butter of a business, it is crucial to protect it.
For the IT and security professionals responsible for managing their company’s GitHub instances, this reliance begs a question that many have yet to consider. How do teams ensure the security of their code, users, and data stored in GitHub? Where do they even start?
Security incidents in GitHub are not all that rare with so many avenues for things to go wrong:
- User security: If a terminated employee with bad intentions still has access, what could they do?
- Organization settings: If a discreet setting is set the wrong way, what could be exposed as a result?
- Repository security: If a repository is publicly visible, what kind of sensitive intellectual property might be exposed?
- Third-party access: If a malicious third-party app is granted elevated access, what might it be able to do?
- Activity monitoring: If suspicious activity was occurring, would GitHub administrators even notice?
In this guide, we’ll wrangle in these five areas of GitHub security, cover how IT and security teams can effectively reduce their security risks, and reveal how Vectrix security scans can continuously monitor for these same issues so that you and your company stay secure.
GitHub User Security
In GitHub, the security of users in an organization is the logical first step to cleaning up and minimizing risks. From simple mistakes to bad actors, ensuring the security of your organization, repositories, and code starts with the people who have access.
4 checks to ensure the security of your users:
❑ Review active users
In GitHub, navigate to your Organization and locate the People tab at the top of the page. Navigate there and you will see all of the people with some access to your GitHub Organization.
On this page, review all of the people present to ensure that they are legitimate users within your organization. Make sure that they are either active employees or contractors of your business.
If any terminated employees or unrecognized users are identified, remove them from your organization and document their removal for future reference.
❑ Ensure appropriate roles
On the same page in GitHub, review active members to ensure that their Role (Owner or Member) in GitHub is appropriate given their job duties.
For example, make sure that members with Owner access are people that require that level of access to perform their job duties.
Where Organization members are found to have more elevated access than what they need, be sure to downgrade their role to Member. You can do this by clicking the settings wheel next to their name and clicking 'Change role...'.
❑ Verify 2FA is enabled
On the same page in GitHub, review the list of active members and ensure that all users have 2FA enabled should your organization require this (a best security practice).
For users without 2FA enabled, contact them directly and request that they enable 2FA in their account. Details on how you can do this can be found here.
❑ Review outside collaborators
On the same page in GitHub, locate the page Outside Collaborators in the left-hand column. Once there, review these users to ensure that the access they have is appropriate.
In GitHub, Outside Collaborators are users that are not full members of your Organization, but people that have been added to specific repositories on a per-repo basis. The most common use case for doing this is allowing contractors access to specific repositories, but not all of them.
GitHub Organization Settings Security
In GitHub, it's critical that administrators oversee and frequently revisit the settings of their Organization to ensure that all settings are in line with security standards and practices. This includes settings that determine how people can access your code and repositories, how changes can be applied to existing code, and more.
4 checks to ensure the security of your settings:
❑ Review member privileges
In GitHub, navigate to your Organization and locate the Settings tab at the top of the page. Navigate there and you will see a running list of the different settings unique to your organization. Once there, locate the page Member privileges in the left-hand navigation column.
On this page, you will find a variety of settings that pertain to how members of your organization can access and manage your code and repositories by default. Based on how your teams use GitHub, it's typically best practice to default to least privilege access.
For the setting Base permissions, the most secure yet practical option is to set it to Read. However, ensure that making this change is known by all members ahead of time as it could limit necessary access.
For the setting Repository forking, the most secure setting is to have this disabled as forking private repositories can potentially allow for sensitive code to be distributed in an unmanaged way.
Lastly, scroll down the page to the section titled Admin repository permissions, and ensure that all associated settings are set so that standard organization members do not have the ability to make changes to repository settings, like changing the visibility or deleting the repository outright.
❑ Verify 2FA is required
On the same Organization settings page, locate the Organization security tab in the left-hand navigation column. Here, enable the setting Require two-factor authentication for everyone should you seek to require all members to have 2FA enabled - an easy security best practice to enforce.
❑ Review Dependabot settings
On the same Organization settings page, locate the Security & analysis tab in the left-hand navigation column.
On this page, you will be able to manage the dependency review settings that are applied to all of your organization's repositories.
Best security practice is to have all three settings enabled, Dependency graph, Dependabot alerts, and Dependabot security updates - with all of them set to be automatically enabled for new repositories as well.
These settings will ensure that any identified security issues within the dependencies you have across your codebase are raised to your team for triaging.
❑ Review Webhooks
On the same Organization settings page, locate the Webooks tab in the left-hand navigation column. On this page, review existing Webhooks and ensure that all are expected and don't raise red flags in their use case. For any that are suspicious, attempt to identify who the Webhook is used by within your organization and seek to understand the use case.
For any Webhooks that cannot be verified, consider removing them as Webhooks allow for external services to be notified when certain events happen.
GitHub Repository Security
In GitHub, repositories are the folders that contain your code and other configurations. It's imperative that the settings for each of your repositories—particularly repositories of critical importance—are maintained and frequently revisited to ensure the security of the code and data they each hold.
4 checks to ensure the security of your repositories:
❑ Review list of repositories
In GitHub, navigate to your Organization and locate the Repositories tab at the top of the page. Navigate there and you will see a list of repositories in your organization.
On this page, simply perform a cursory review of the existing repositories while keeping an eye out for any red flags or suspicious behavior when it comes to existing repositories. Take action as necessary.
❑ Review user access to critical repositories
For repositories that you deem critical—repositories that power your product, repositories that contain sensitive code or data, etc.—perform a repository-specific user access review.
To do this, navigate to each of the critical repositories in question and identify the Settings tab at the top of the page. Once there, locate the page Manage access in the left-hand navigation bar.
On this page, review access settings as well as any members or teams that have a specific level of access configured for that repository.
Where any excess permissions have been granted, take action to minimize what is accessible. This can include removing members should it be found that their access is not necessary for performing their job duties.
❑ Review Dependabot settings in critical repositories
In the same repositories deemed to be critical, navigate to each of their respective Security & analysis pages and ensure that the dependency-related security settings are enabled where appropriate.
❑ Review Branch Protection settings
In the same repositories deemed to be critical, navigate to each of their respective Branches pages and ensure that Branch Protection settings are appropriately enabled and configured. Branch protection settings ensure that version control-based changes are applied in a coordinated, verified manner.
For these critical repositories, ensure that there are Branch protection rules applied to the Default branch listed on this page.
Next, review the settings of the Branch protection rules by clicking Edit for the specific branch rules. Best security practice says that settings should be configured to ensure checks and approvals are necessary to have new code applied or existing code updated.
This includes enabling the setting Require a pull request before merging with at least one approval required. Further, enabling the setting Include administrators will ensure that all rules set here will also apply to organization and repository administrators.
Lastly, depending on your level of strictness, it's also best practice to disable the settings Allow force pushes and Allow deletions, which can be found at the bottom of the page.
Third-party access security in GitHub
In GitHub, it's critical that you review any third-party access that has been granted to your organization and/or code to ensure that it's not only granted to legitimate parties/services but granted at the appropriate level of access as well.
2 checks to ensure the security of third-party access:
❑ Review approved third-party application access
Navigate back to your Organization and locate the Settings tab at the top of the page. Once there, locate the page Third-party access page in the left-hand navigation column.
Here, review the policy listed at the top of the page and ensure that it is set to Access restricted so that only approved applications can access data in your organization.
Next, review the list of approved third-party applications and make sure that they are both recognizable and legitimate in having access to your organization. If there is a suspicious or unknown third-party application listed, seek to find the owner and determine the intended reason for having access. If you are unable to do this, remove the application's access.
❑ Review installed GitHub Apps
On the same Organization settings page, locate the Installed GitHub Apps tab in the left-hand navigation column.
Once there, review each of the GitHub apps listed. For any that seem unnecessary or cannot be deemed as legitimate, seek to confirm the purpose of their access. You can do this by attempting to identify the person who added the application and asking them the intended use cases of the application.
Further, review the GitHub apps listed and ensure that the access they have is appropriate and minimized where possible. You can do this by clicking the Configure button next to each application - here, you will be able to review what permissions the application has, the repositories it has access to, and more. Where you deem access or settings to be elevated or outright inappropriate, take action to make those changes.
Activity monitoring in GitHub
Lastly, it's good practice to occasionally—or more frequently—review the activity going on across your GitHub organization. This includes activity around code changes, settings changes, user additions and deletions, and more.
Often this particular activity is the first step in identifying the source of suspicious or outright malicious behavior in the case of a security incident.
❑ Review audit log for anomalous activity
On the same Organization settings page, locate the Audit log tab in the left-hand navigation column.
On this page, review the outlined activity displayed. As you will see, there is a variety of expected behavior captured in this audit log, but learn how to search and filter this page to ensure your ability to discover anomalous behavior should any suspicious activity occur.
You can also export this audit log to review in another application of choice.
Wrangling it all together
Most IT and security teams acknowledge the inherent security liability GitHub poses, but that doesn’t minimize the effort required to effectively secure the platform. It’s not uncommon for smaller teams to not know where to begin or where to look for security issues in the first place.
Guides like these can help clean up what was problematic to start, but things change, and it’s important to recognize that without frequent, ongoing monitoring, these same issues can be reintroduced just as quickly as they were fixed. So if one-time reviews aren’t enough for you and your organization, check out the Vectrix platform to see which SaaS tools you can scan and continuously monitor for security issues in just a few clicks.