GitHub Security Best Practices – 15 Tips To Keep In Mind

What makes GitHub stand out of others? Let’s see… It is the largest source code hosting platform, used by 100M+ developers. And with its growth it has become an integral part of the DevOps workflow. Every CTO or DevSecOps understands that neglecting the aspects of Git security can lead to serious consequences. Data breaches, financial loss, data corruption, reputation and stock price loss are just some of them. 

If the company evaluates all those risks connected to using GitHub and takes preventive measures to mitigate those risks, it can both save its critical and sensitive information and keep its business continuity stable.  In this blog post we will speak about how to build GitHub Advanced Security, but before let’s look at the risks your GitHub Cloud Infrastructure or GitHub Enterprise can face. 

It’s time to evaluate the risks…

Why is it important to take all the preventive measures to protect your GitHub environment? Let’s look at the track of the security threats, such as malware and ransomware activity on GitHub in the latest couple of years:

• 2019 – A group of malware researchers from Trend Micro uncovered a watering hole campaign that involved the new variant of malware, abusing Slack and GitHub, consequently named as SLUB.  
• 2020 – The GitHub’s Security Incident Response Team issues the notice that some GitHub repositories using open-source Java projects are infected with the malicious code.
• April 2022 – Attackers steal the login details of 100K npm accounts with the help of the stolen OAuth app tokens issued to Heroku and Travis-CI. (Read more about how NPM packages can be compromised here)
• October 2022 – Checkmarx Supply Chain Security team notices a flaw that allows attackers to take control over repositories and infect codes and apps with malware.
• November 2022 – Discloses a security breach after threat actors stole 130 code repos and gained access to one of its GitHub accounts using employee credentials stolen in a phishing attack.

In a nutshell: we can say that there have already been tons and thousands of data points, sensitive and valuable information stolen, corrupted or leaked causing enterprises to spend thousands or even millions of dollars to overcome those problems. Take a look at our Ultimate Review of the most infamous GitHub-related security incidents (let’s be honest, “fackups”) of 2022.

Just imagine, the average ransomware demand for a single victim makes up around $570K…. And it is just a ransom, what about other expenses, like time of downtime – which can last up to 22 days (sic!). Or what if the malicious actor refuses to return the access to your data? About 92% of those who paid the ransom were unable to get all their data back without a loss. So, there are a number of concerns… 

GitHub Security Best Practices

All the mentioned statistics and facts are scary, but there is a way to eliminate those troublesome consequences or even overcome them, saving nerves and budget.  

Tip # 1 – Don’t store your credentials on GitHub

According to Dark Reading in 2021 the enterprises leaked over 6M passwords, API keys and other sensitive data. Why? Because DevOps tend to keep their so-called “secrets” in their GitHub repository. And then share their repos with their teammates or the entire company.

Thus, the first thing you should always take care of is your GitHub secrets. Why is that so vital? Because such data can easily be compromised and if so you can lose not only your personal access data, but also the whole project – months or even years of hard work and loads of money.

To your luck, GitHub has preventive measures to help your security in this case – GitHub secret scanning. The service scans your entire Git history on all branches in your GitHub repository for leaked login credentials. If it notices some username or password in code or commit metadata, it can automatically reset your sensitive information and notify you via email. Sounds nice

GitHub provides secret scanning in two forms: 

• partner pattern secret scanning, which runs automatically on public repositories. 
• advanced security secret scanning, which is an additional scanning for repositories owned by the organizations using GitHub Enterprise Cloud. 

There are also third-party tools to boost your capabilities for secret detection that scan your code to detect hidden passwords, certificated, API or encryption keys to discover vulnerabilities early and remediate immediately. Let’s just mention GitGuardian secret scanning.

Tip # 2 – Restrict and control granted access 

One of the main reasons for data breaches as we have already mentioned is the leak of credentials. Now let’s look at this from another angle. The main question here is who granted access to your sensitive data?

For example, you have some temporary developer who joined your DevOps team just for a short period of time and then, after his job has been done and he left the company, your security teams have forgotten to restrict his access. Is that possible? Sure… human mistakes are among the most popular results of data loss. 

That’s why proper protection of the password details and the control over whom the access is granted should be always monitored.

Remember about the least privilege rule that can protect you from malicious access and errors.

Tip # 3 – Use GitHub teams

Should everybody of your DevOps team have the same access to every repository? Definitely not. Thus, it is vital to create teams for your organization’s workflows. You can create teams of developers, security engineers, and many other within your organization’s needs and requirements. Moreover, you can grant each of those teams with proper access, e.g. admin, write, or only read.

Tip # 4 – Use 2FA or MFA

Even if you have a strong and reliable password – as you think, it can be compromised. You may use over 16 random characters of lower and upper case, numbers, and signs, but it still can be broken. Is it possible to strengthen the password? Yeap… use 2-factor authentication.

This way of protection serves as an extra layer of security protection during your login process. In addition to the usual information that you provide to log in to your account – username and password, you need to provide some extra piece of data which is known only to you, or you can prove your identity using a device of your personal use. For example, you get a message with a 2FA code or a call on your cell phone.

By the way, GitHub strongly urges you to enable two-factor authentication and provides you with a 2FA recovery code in case you lose access to the telephone. Moreover, GitHub will require all users to enable 2FA by the end of 2023.

On the other hand, for more vital information and N-times stronger security you can enable multiple-factor authentication. In this case you add more than one piece of extra information and/or device that is known and used only by you.

Tip # 5 – Rotate personal access tokens and SSH keys

You may prefer to use personal access tokens or SSH keys and give up using “common” passwords for authentication to your GitHub account. 

Though, don’t forget that it’s worth refreshing them regularly. Another good idea is to protect it with a passphrase or generate your SSH keys on a hardware security key. This will secure and mitigate potential damage that can lead to your data being leaked or stolen. As if a threat actor gains access to your SSH key, he will be able to push a malicious code to your repo.

Tip # 6 – Ensure code branch protection

GitHub as a service provider has its own set of rules for managing branch protection. It permits users to create such rules in a repository for a single branch, when we speak about some specifications, or all branches in a repository. Though, it’s worth paying attention that if we speak about branches that you want to specify, you shouldn’t forget to use fnmatch syntax. 

You may ask why do I need a branch protection as a git security measure? Yet the answer is simple – it reduces the risk of internal threats from one side, and helps avoid pushing the unwanted code into production from the other. 

To be more precise let’s look at measures and security features GitHub recommends to take:

• allow force pushes and deletions
• restrict the access to those who can push to matching branches
• lock branch
• check the required pull request review, status checks and conversation resolution before merging
• check required signed commits
• require linear history and merge queue
• require deployments to succeed before merging. 

Tip # 7 – Don’t forget to create a SECURITY.md file

Why is it worth including a SECURITY.md file to your development process? Like README.md file, SECURITY.md file contains information about your project. While the first one gives only the general overview of the project, the second one represents the set of instructions  which should be followed during a report about security vulnerabilities in your project. Thus, it should include:

• Disclosure policy, which defines the procedure of how the users should communicate about the discovered information and who they should be in contact with on that issue.  
• Security Update policy, which defines the process of communication of the found vulnerabilities to others.
• Security-related configuration, which includes the settings that help strengthen the security posture during the project deployment.
• Future enhancement and known security gaps, which includes some security improvements that your organization hasn’t implemented yet. 

Tip # 8 – Disable forking

From the development side, git forking may seem a convenient option for your DevOps team, as it permits you to make a copy of the project and make changes to it without affecting the main branch. Though, from the security side, it has its downsides. First, forking slows down the process of security tracking and makes it a little bit more complicated.

Then, forking gives the possibility to fork all code repos to every member of your DevOps team. What if it is a temporary developer in your team? What will happen if he forks the build for his personal use? The build of your team on which you were working for a long time and put loads of energy, effort and budget?

Tip # 9 – Think twice which GitHub app to include

It’s not a secret that GitHub apps are very useful when it comes to the development process. It can simplify DevOps building and development process, though are all the applications secure? 

It is incredibly important to be attentive when you choose any app to add as a feature to your CI/CD process. What you need to do is to read all the reviews thoroughly on how secure software is, check out its producers, and think twice before granting access to any third-party app. You can check its trustworthiness and if it takes all security measures to keep your data protected. For example, if that third-party solution meets SOC 2 or ISO 27K requirements.

Tip # 10 – Backup your GitHub environment

Regular backups can help to withstand different unpleasant situations, like GitHub outages, or ransomware attacks. Though, to have your data secured and easily recoverable from any point in time, it’s better to use the GitHub backup best practices, including:

• data to backup – make sure that it includes all your GitHub repositories and metadata
• storage choice – it’s worth choosing a few backup destinations to store your data
• unlimited retention – that guarantees that your projects will be stored up to forever
• 3-2-1 backup rule fulfillment – when you have at least 3 copies of your vital data in 2 different storage instances, one of which is offsite
• ransomware protection – a set of features, that will empower your DevOps team with a confidence that the source code build is well-secured
• encryption – which permits to encrypt the data in-flight and at rest even with your own encryption key
• automated backups – which can be implemented into your CI/CD process.

You, as a CTO or a Security Leader can assign some members of your team to write scripts and perform backups on a regular basis – though, it can be time-consuming. On the other hand, you can use a third-party software, like GitProtect.io which will take the responsibilities of data backup and guarantee data accessibility and recoverability.  

---

Eliminate data loss risk and ensure business continuity with
the first TRUE Disaster Recovery software for GitHub.

---

Tip # 11 – Track the activities via Audit logs

If the organization has a rather complicated structure and a large number of employees, it is a good idea to use Audit logs to track the activity of all the employees from time to time. Audit logs contain the details on who performed the action, when this action was performed and what action it was. 

Tip # 12 – Regularly scan your repos

Regular scans for vulnerabilities and bugs can bring more peace to you and your organization itself as your DevOps team will have an opportunity to detect and solve the problems faster. GitHub has its own code scanning feature that can be used for these purposes or you can implement a third-party software, like above mentioned GitGuardian, to scan, detect and remediate bugs in your development process. It will help developers prevent creating new security troubles and work peacefully. 

Tip # 13 – Keep your private repositories safe

If you don’t need to use public repositories in your organization, then it’s worth disabling the creation of one. You can easily do it within your GitHub account. It is important as it prevents any member of your DevOps team from accidentally creating publicly accessible repositories. What is more, it reduces the possibility of human mistakes.

Tip # 14 – Manage IP addresses

It is very important to track your DevOps team’s actions, though it might be difficult. As a security measure you can restrict access to your company’s private assets. What is the best way to do that? Configuring the list of IP addresses allowed to connect. 

Using this option, you can grant access only from the IP address of your office network. If you have a remote team, you can approve each single IP access using CIDR notation. Thus, you will have a guarantee that the addresses out of your IP allow list are blocked to the private resources via API, web, or Git.  

Tip # 15 – Check source code before importing it into GitHub

It is nice to have a rule to perform a complete audit of your code before importing it to GitHub. It may seem an unimportant issue – to audit a small project, yet imagine that this project grows every day… How much time will your DevOps team need to perform a full audit, update and then pull it? Weeks or even months. Thus, audit of smaller parts may seem reasonable. 

Takeaway

GitHub is an incredibly useful git code management system, yet you shouldn’t underestimate its security. It is important to follow simple steps to protect your intellectual property and assets, which source code is. You can use the features GitHub provides, though don’t forget that GitHub is a service. And as any other SaaS it operates in accordance with the Shared Responsibility Model. What does it mean? The security of your source code is your own duty under the Shared responsibility Model.  

With the plethora of features available on GitHub, make sure that you use all necessary ones that will help you to build a reliable secure space for your DevOps team’s continuous coding.