10 GitHub Security Best Practices

GitHub is a standard when it comes to sharing code among developers. It is the most essential platform used by developers in every company, and despite the broad usage, there are still bad practices made and they can cause source code leaks, or even credential leaks.

Taking into consideration many of those bad practices we prepared a list of 10 good ones you can follow to have a more secure sharing and collaboration in GitHub. In this blog post, we give you that list of 10 best practices you can carry out to resolve or prevent security issues having to do with your GitHub repositories. Keeping your GitHub accounts secure means keeping your company secure.

Digital or not, security is the top priority for all companies, that’s why you need to consider adding these practices to your security requirement list. Now, here we go.

1. Never ever store credentials or secrets in GitHub

Starting off with the basic – leaks of login credentials, API keys, private tokens, SSH keys. These are the heart of security and by pushing them (accidentally or not) into your company repos you are leaving a door open for cybercriminals. Private repositories might seem like a safe place to hardcode your secrets for your team to access them, but sometimes third-party services may have access to those repos, too. Why is that dangerous – well, your third parties can be exploited in the future, and your secrets won’t be too private anymore.

It is not quite unusual to see leaks of credentials even in public repositories – after that, it is important to go and delete them from the repo. However, that won’t get the job done since you need to clean the history as well (practice 3).

What to do about it 

1. The best tip we can give you – is to use shared credential vault tools to inject secrets as environment variables externally from the source code or documentation and make sure everyone in the team uses it. Examples of those tools are LastPass, Zoho Vault, Dashlane, and so many others. This allows you to have stronger passwords and reduces the chances for them to be stolen.
2. You can also scan your commits to prevent pushing secrets, and there are tools to do that. Tools like Git-secrets will not allow you to commit any code containing secrets you previously assign as sensitive information. 
3. Another thing you can do to prevent leaks is to build a pre-commit hook with Git hooks and check every pull request for any secret

2. Give importance to access control

Once your company allows users to access its GitHub repositories, it is very important to follow a few steps to control that access. It is advised to use the least privilege model for granting users access, which gives users only minimal but necessary permission to access resources. This limits inappropriate exposure of information.

In case you have inactive team members who are not currently contributing to your codebase – just remove them. In other cases when an employee no longer works for the company, even quicker action needs to be taken. You need to revoke their access before any possibility of a malicious insider comes to the fore.

Default passwords are also advised to be changed, but you also need to update them once in a while. This reduces any possibility of unauthorized access.

Companies need to secure access also using 2-factor-authentication (2FA). GitHub account leaks can not only affect public repositories, but also private ones, and for companies that means leak of source code, also sensitive information if attackers gain access to any database credentials.

3. Remove sensitive data before it is too late

Practice 1 tells you to be careful with secrets and not store them in your commits. What if a member of your team hasn’t been careful and has leaked a secret? – That is time for immediate action. There are a number of things that need to be done:

• First off, get rid of the secrets that were public, because the fastest way to an exploited vulnerability will possibly be from there
• Then remove that secret from your repo! Even an old password can be a clue for threat actors.
• Last but not least – Do not forget the ‘history’!!! GitHub keeps a history of all your commits, and attackers will check that, too – in hopes you have forgotten something there.

You will follow these steps in case you are aware of a leak. But you can’t always know what is dug in all those lines of code. A good practice is to scan your repos with tools like GitRob or truffleeHog and find leaked secrets. To get more information, you can go on and read our series of blogs about GitHub tools.

4. Archive

You don’t need to delete everything that isn’t actively developed and not maintained anymore, you can simply archive it, and when you need that repo back, go and unarchive it. Archiving repositories makes them read-only (even to the owner). Pull request, labels, projects, releases, commits, branches, comments – basically everything becomes read-only. However, you can still fork these repos.

A good practice would also be to update the README file to inform users that contribution is no longer possible.

5. Give some importance to Branches

Developers use branches to separate parts of their code so that everything will be clean in the repository. For example, when you add new features to your code or even fix a bug, it is better to add them in separate branches, to make sure the main code remains as it is until you are completely sure the new feature/bug-fix works properly. Only then, it is advised to merge it, and you can do that using a pull request.

Here are some tips when it comes to using branches:

• Use a branch naming convention to keep your repository organized even in large teams
• Delete branches that you have merged to others if you won’t be developing them anymore

You don’t want any “This branch is out-of-date with the base branch” message, right? Then, constantly merge your base branch into that branch you are working on, and keep your branches up to date.

6. Be aware of security leaks – audit – update (Review your code and update)

Reviewing the code before importing it into a public GitHub repo is one of the key practices every company should follow. It will help you find the bad security practices of any member of the team.

A practice that will help you review the code easier and faster is mentioned in 7 – that is assigning Owners to each code. For smaller projects, auditing the source code might be easy, but organizational projects usually have a large-sized codebase. These projects can take weeks, even months to fully be reviewed or updated.

7. Keep an eye on team members

There is usually a large number of members who work on a project and it is sometimes difficult to keep up with everyone. Not all developers need to have access to every repository on GitHub. It is highly recommended by GitHub to give access only to members that are really working with a team and need access to a repository. Another important practice is to define code owners as early as possible. A code owner can access all teams and repositories of a company – a mistake in defining them can lead to huge consequences!

8. Don’t ignore .gitignore

When you commit a project in GitHub, you will not always want to include every file in version control (for example build files, editor backup files, local config overrides, cache files, OS-specific files, even some databases, etc.). GitHub encourages users to create a .gitignore file where you can put everything you want to be ignored and not added to the repository.

The reason for adding a .gitignore file is to make your commits easier. In large-sized codes, it can be exhausting to add every single file one by one. Users can commit the whole project and then add to .gitignore only the files/folders they want to exclude from being committed or pushed to the repository.

Users can ignore a specific file by giving the full path to it, ignore files with a certain name by only giving filename, ignore a certain file type, or a certain folder.

In case you aren’t sure how to start creating a .gitignore file, choose templates from Gitignore.io

9. Add SECURITY.md file

You are all quite familiar with the README.md file because it is a must for all repositories. So has to be the SECURITY.md file and it has actually started to appear a lot in repositories. This file is a security policy for other users which tells them how to responsibly report security vulnerabilities.

Some of the topics SECURITY.md file needs to contain are as follows:

• Steps that need to be taken in case a user finds a vulnerability in your code
• How you will inform users about newly found vulnerabilities
• Information about incomplete security controls 
• And anything else, that your company considers as valuable security information for its users

10. Don’t forget to patch

Last but not least – Patching your Git repository. Failure to patch your code has great consequences when it comes to GitHub security.

From practice 9 you know the importance of a SECURITY.md file. However, there is no importance left to it if your project maintainers do not show any effort to address those vulnerabilities reported by other users or even found by your team.

It is strictly advised to stay updated with new vulnerabilities. When you find one, do your patches as quickly as possible and do not let time for threat actors to exploit that vulnerability.

How does SOCRadar help you find exposed data on Github?

SOCRadar monitors a vast number of GitHub repositories and analyzes their content. It rapidly detects mentions related to your company. SOCRadar also informs companies about any information that might have gone public and checks if any credentials have leaked.

Account credentials of your customers or employees, credit cards, PII, or any other sensitive information related to your company is being monitored constantly.

At SOCRadar, we leverage our Machine Learning and AI technology to normalize and classify terabytes of processed data and deliver actionable threat intelligence to SOC teams.

Would you like to discover if your data is exposed? Get Started