GitHub is the largest source code host in the world, used by over 73 million developers, 4 million organizations and hosts over 200 million repositories.
As an organizations’ team grow, GitHub security can become more complicated and difficult to track. Additionally, GitHub's security misconfigurations, public repositories, and hardcoded credentials could attract attackers. Today, we’re going to talk about 10 GitHub security best practices and why we should configure them. Let’s get started together!
Most developers tend to store sensitive data such as API keys, database usernames/passwords, and private keys in their GitHub repositories. This is the easiest way to deal with a functional coding problem, but the worst method in terms of security. According to a recent study, on average, three out of every 1,000 GitHub entries leaked a secret.
GitHub repositories are meant to be shared, with your teammates, your company, and even publicly. However, not every secret needs to be shared with everyone. For example, when a temporary developer joins the repository to solve a quick problem and then the team forgets the delete the developers' access to the repository. A mistake like this could allow an attacker to capture developers’ password and steal all the secrets from the repository. Besides user credentials being captured, all company secret keys are leaked, leading to a companywide security disaster.
Additionally, there’s a risk that the source code could be leaked. Sometimes repositories are accidentally created to be publicly accessible and attackers seize this opportunity to steal secrets. Additionally, developers might work within a local copy of the repository, creating the possibility of a leak due to malware, hacking or accidental disclosure. Attackers can get all secrets from local copies, leading to a disaster.
To prevent accidentally leaving secrets into the GitHub repository, you can use several helpful open source tools such as git-secrets. You can audit your repositories using tools such as truffleHog for your regular checks.
As you know, using strong passwords isn’t secure enough anymore. Attackers have developed several tested methods of stealing credentials, giving them unauthorized access to our accounts. For this reason, it has become very important to enable MFA for all your GitHub user accounts, as it is in any account. Besides MFA enabling, you should enforce MFA for every GitHub user in your organization. To require MFA, select Your Profile Photo → Your Organizations→ Settings → Security →Authentication Security. You can see all the details here.
In addition to the README.md file, you need to include a SECURITY.md file that includes security information for your project. SECURITY.md file should contain:
- Disclosure policy: You need to define the procedure for the person that found security issues, and who the contact is for them. You can configure the ‘security@’ email.
- Security Update policy: You need to define how you intend to update users about new security vulnerabilities as they are found.
- Security-related configuration: This includes settings that users should consider that would impact the security posture of deploying this project.
- Known security gaps & future enhancements. This includes security improvements you haven’t implemented yet.
Forking means creating a copy of a repository that we manage. The fork option is very useful in such cases because it allows us to make changes to a project without affecting the original repository. However, from a GitHub security perspective, forking makes tracking of security issues much more difficult. Additionally, repository users can fork all code repositories to their private accounts. To disable/enable the forking option, select Your Profile Photo → Your Organizations→ Settings→ Member Privileges. In the repository forking section, you can see the disable/enable option.
GitHub applications are very useful for adding several features to our repositories, however it's important to be careful. Before adding a GitHub application, you need to review the applications and their credibility. If applications have any security issues, negative comments, or unknown authors, you need to think twice before authorizing your GitHub organization. Additionally, for each application, you need to audit the permissions they require and make sure they do not have more permissions than necessary. You should review both the “Third-party access” and “Installed Github Apps” regularly to make sure no unauthorized access is granted.
If your organization does not require public repositories, you need to disable public access to prevent the accidental creation of publicly accessible repositories. To do this, select Your Profile Photo → Your Organizations→ Settings→ Member Privileges. In the repository creation section, you can see the settings.
Not everyone in your organization needs access to every repository. It's important to create teams for your organization's workflows such as developers, security engineers, managers, etc. You can also set a specific role for each repository such as read, write, and admin. Always consider the least privilege principle for each case.
Tracking everyone’s actions is very important yet is often difficult for large organizations. When someone leaves the organization and is not deleted from the repositories, it can be very dangerous.
Additionally, when an attacker captures a GitHub user’s password with different methods, they can gain full access to the organization’s repositories. To prevent these situations, you need to use IP whitelisting for your GitHub organizations as an additional method of security. You can use your VPN or office network CIDR for this.
*Note: You need to use GitHub Enterprise for IP whitelisting option.*
Regular code scanning allows vulnerabilities to be easily detected and addressed as soon as possible. For your GitHub repositories, you can use the code scanning feature in GitHub or you can use third-party sources such as SonarQube. Scanning your repositories regularly helps you to locate and fix existing security vulnerabilities. It also prevents developers from creating new security problems. This can be achieved by defining new workflows, as well as new push/pull mechanisms. For example, when a new vulnerability is found in code, your repository would not allow the process to continue.
The GitHub audit log allows organizations to quickly review actions performed by members of their organization. It includes details such as who performed the action, what the action was, and when it was performed. It's important to periodically review the audit log and make sure that there are no anomalous or suspicious activities.
GitHub is the world’s largest code management system, but it's still important to be sure your code is being stored securely. In this blog, we’ve summarized 10 GitHub Security Best Practices to help protect your sensitive data. We've also shared some useful steps that you can use in these practices. We hope you enjoyed it! Start implementing these practices today to stay secure in GitHub!
Check out our Devops services to start your digital transformation!