What are GitHub security best practices?

GitHub security best practices are a set of tasks designed to reduce the attack surface of your GitHub account and of each repository.

1. Implement access control

Sometimes the best way to prevent malicious users from accessing your GitHub repositories is the simplest and most obvious one. It takes only one developer to lose their credentials written on a sticky note, or one unlocked computer in the train for an attacker to gain access. So implementing basic settings and practices on GitHub will help reduce the risk. Implement the following best practices:

• Require 2-factor-authentication on every contributor’s GitHub account including (and especially) outsourced developers!
• Use complex passwords and a password manager and never let users share GitHub accounts or passwords.
• Secure your hardware: laptops or even mobile devices with access to the source code are a potential entry point for attackers.
• Revoke access from former employees or contractors. Often, their GitHub account is a personal account so just revoking their professional email account won’t be enough.
• Abide by the Principle of Least privilege: contributors can only access the data they need to do their work and nothing more.

---

2. Be mindful of applications you install from the GitHub marketplace

Applications from the GitHub marketplace are written by third-party developers, so you need to be particularly careful when installing GitHub marketplace apps. Make sure you include the following steps to your selection and installation process:

• Validate that the author of the application is legitimate before giving them access to your repositories, as you would do for a new contributor to your code. Note that the number of installs is rarely an indication of trustworthiness in cybersecurity.
• Apply the Principle of Least privilege and never give applications more rights than needed. Ponder the question: what damage could they do with this level of access?
  

The Solarwinds and Codecov breaches are still fresh in our minds: if you install unsecured applications, your application could be collateral damage.

---

3. Add security testing during development

GitHub allows you to send HTTP POST requests to a service of your choice using Git hooks. Git hooks are scripts that are triggered by certain actions in the software development process, like committing or pushing. Many static code analysis tools support Git hooks so you can perform security checks during the software development process. Pull requests are a useful event for that purpose, as they are purely informational by default and thus don’t have to block a merge. You’ll be able to warn developers against adding vulnerable pieces of code. But keep in mind Git hooks won’t help with vulnerable code that is already live.

---

4. Rotate Personal Access Tokens and SSH keys

An SSH key is a way to identify yourself that doesn’t require you to enter your username and password every time you log in to GitHub.

Personal Access Tokens are an alternative to passwords for authentication to GitHub when using the GitHub API or the command line.

You want to make sure both SSH keys and Personal Access Tokens are rotated regularly to mitigate damage in case they are stolen or leaked.

---

‍5. Switch to GitHub on-premise

Financial institutions, Government agencies, and other tightly regulated industries sometimes prefer to restrict employees to software that can only run locally - or “on-premise”.

Thankfully, this does not prevent you from using GitHub thanks to the on-prem GitHub Enterprise offering. Even GitHub won’t be able to access your code as everything runs locally, even offline.

However, this does not mean that any smaller companies mindful about securing GitHub should switch to on-premise. Implementing security measures on-premise is costly. So on a startup budget, cloud applications might be more secure than on-premise applications.

---

6. Never hardcode credentials in GitHub

Not convinced of how big of a deal this is? Just type “removed API key” in the GitHub search bar to find - at the time of writing - 800,000 commits containing tons of valid tokens!

How can you be sure none of the credentials on public GitHub belong to your company? Let’s start by introducing a key notion regarding GitHub security.

Developers contribute both to private repositories, internal to an organization, and to public repositories. Some of those public repositories might belong to your enterprise. But developers also contribute to open source projects or work on personal projects in their free time.

In 2020 and after 3 years of research, our CEO already mentioned that less than 20% of corporate leaks on GitHub occur within public repositories owned by organizations. Data shows that the majority of the remaining leaks actually occur on developers’ personal repositories. This happens because users often have the same Git account for personal and professional work projects on the same machine. If you don’t know how to set up multiple Git accounts, we have a cheat sheet for that!

Using the GitHub search bar to find secrets can only get you so far. First, implement proper secrets management to reduce the risk of secrets reaching the repositories. Then, implement secrets scanning on both private repositories and on public GitHub to get an alert in the event of an incident on any repository.

Once you’ve been alerted, simply remediate the incident, usually by rotating the API key. Sometimes you can also rewrite your Git history - it can be worth the effort for a smaller organization, but it is rarely the case for enterprise users.

---

7. Secure by design

In software engineering, secure by design means that software products are designed to be secure right from the start. How much easier would it be if the right security processes were in place before the first line of code ever hit your GitHub repositories?

In the real world, developers are often happy to the path of least resistance to get an application up and running. Which often means hardcoded passwords or stored locally in config.

Internal code should be written with an open source mindset. Your developers will write better and more secure code if they know others will see it - and potentially exploit it.

Also, should you ever want to open source your code, it will become a lot easier and safer to do so when security is implemented by design.