Github is amazing. I love it, you love it and pretty much every other developer loves Github too.
Most open-source projects live on Github, and it’s super easy to collaborate with teams there. But, as with any type of massive growth, over time, Github added more features, became more complex, technology and security changed and some of the default settings no longer aligned with security best practices.
So, it’s important to review settings, and understand where and how to implement better security as the company wide de facto practice.
Secure Github and Protect Your Source Code
Github authentication & access
Standard login to Github is via basic credentials, a username and password. But we recommend requiring more secure authentication flows since the username is public, which means once attackers locate the password for an account (using social engineering, data from prior breaches, or other nefarious means) they can easily login and gain user access to the SCM.
2-factor authentication
If you haven’t already, the most basic practice to implement is to require that all teams, employees, and contractors set up 2FA in Github:
SSO (GitHub enterprise only)
SAML authentication for your organization through an identity provider is available for GitHub Enterprise users. if you have the option, implement it.
Limit access to specific IP addresses
You can restrict access to your organization’s assets by configuring a list of IP addresses that are allowed to connect by setting the “IP allow list” configuration.
Repository Access
Base permissions
These are the base permissions every member of the organization receives. The most secure option here is to set it to none. This will require permissions for repositories to be set explicitly for each repository based on user or teams.
Outside collaborators
Outside collaborators are users with access to a private repository that are not part of the organization. We strongly recommend that outside collaborators are tightly controlled, with as minimal access as possible. They should be monitored at all times.
View current access permissions
Github recently added a feature that allows users to inspect access on a per repository basis.
In the repository settings navigate to: ‘Settings -> Manage Access’ to see an overview of the access permissions to that repository:
Leak Prevention
Disable forking (org + repo)
Forking is the act of creating a copy of a specific repository. Forking is meant to allow developers to create a copy where they can experiment on the code without affecting the original repository .
From a security perspective, there are two main issues with forking. The first is that the more forks there are for a repository it is harder to keep track of the security of each fork, and the problem of securing the repository grows exponentially the more forks a repository has. The second is that forking can easily be used to create a copy of a repository in a user’s private account. Very dangerous.
There are two types of forking:
- Organization forking settings. This is a cross organization settings that will apply to all repositories.
- Per repository settings.
Disable visibility changes
View settings for visibility changes.
This will prevent developers from changing the visibility from private to public repositories.
Disable public repositories
If you have no need for public repositories, or have an organization that is entirely dedicated to proprietary code, then you can disable public repositories across the organization.
Tampering Protection
Enable branch protection rules
Github comes with built-in controls meant to enforce tempering protection through workflow definitions. The most basic of them is requiring code review before merging code to the production branch.
This makes sure that a developer cannot push code that hasn’t been reviewed by another developer to the production environment. These settings can be found under each repository’s configurations.
As you can see, you can control the number of reviewers needed to approve a commit. You can also require that the code owners themselves approve commits.
Another setting important to know in this context: Require signed commits. This means every commit is signed by a developer and can be attributed back to someone aka totally and easily traceable.
Source Code Security
Enable dependency checks
Github comes with built-in support for dependency vulnerability checks after acquiring dependabot. However, this setting needs to be turned on on a per-repository basis.
Once a dependency vulnerability has been identified, an alert will be created and if possible an automated pull request will be created to mitigate the issue. Under the security alerts section in the repository settings, you can define who will be notified when a security issue is identified.
Review Your Audit Log
Under the organization’s settings, you can access the audit log and view various events that happened in Github. Periodically review the audit log and make sure that there are no anomalous or suspicious activities.
Inspect Third Party Access and Github Applications
Github allows you to grant access to third party applications. On the organization settings review both the “Third-party access” and “Installed Github Apps” to make sure no unauthorized access is granted.
How to automate security best practices with Cycode
Cycode can help with source code security by addressing your organization’s settings in OS platforms by automatically inspecting the security posture across Github’s settings. We analyze actual usage and recommend tightening the access model to fit a least-privileged approach.
We monitor the SCM activity in real-time allowing us to alert you to various security-related incidents based on the policy that best suits and protects your organization.
