GitHub security best practices are a set of tasks designed to reduce the attack surface of your GitHub account and of each repository.
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:
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:
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.
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.
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.
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.
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.