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
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 in 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:
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.
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 from the master 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 from your master, 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 with the master, and you can do that using a pull request.
Here are some tips when it comes to using branches:
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 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:
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