Top Git Security Issues & How to Avoid Them

Git is a distributed version control system used by a massive number of developers all around the world. Millions use this open-source system in combination with popular Git code hosting platforms like GitHub, GitLab, and Bitbucket. 

Git hosting solutions provide top-notch security features to protect the monumental amounts of repositories hosted on the platform. Unfortunately, most Git hosting services are substantially secure, while your repository might not be. Like any other security system in the world, Git has its fair share of loopholes that might lead to various security issues — ranging from simple configuration mistakes to complete exposure of sensitive information.

Once an attacker gains control of your account, they can do everything from stealing code or secrets to completely destroying your development environment. That's why it is essential to be aware of the top Git security issues. 

Why hackers are targeting Git

Today, companies of all sizes use Git and Git repository hosting platforms to handle small to extensive projects. Albeit the benefits like developer collaboration, speed, and productivity, the tiniest gap in your security posture could result in data breaches, hence millions of dollars and a blow to your company's reputation in the worst-case scenario. 

There are a few reasons that draw hackers to GitHub and other Git hosting platforms. Some are as the following:

• Source code: Software stored in Git is a valuable mine for hackers. Stealing the code would enable other companies or even nations to copy the code and develop derivatives of the stolen application without paying license fees. Malicious actors might also steal the code and resell it, or they may ask for ransom in return for your information.
• Access credentials for other services: The code and files on Git might inadvertently contain critical login credentials for other services, such as AWS or Azure. Stolen login credentials assist hackers in bypassing organizations' security measures and accessing sensitive data. (This is why multi-factor authentication plays a vital role in cybersecurity.)

7 Git security issues & tips to avoid them

1. Hardcoding sensitive data

The first Git security mistake you must be aware of is hardcoding sensitive information. Admittedly, it's tempting for developers to store credentials like passwords, authentication keys, and tokens right inside the code where the credentials are used. However convenient as it may be, it could be the worst security mistake for software development. 

When you hardcode sensitive data, you basically leave the valuable information in plain text, which is easy to read and get exposed by attackers. Anyone with access to your Git files can decompile and discover sensitive information. 

To prevent secrets from accidentally or even temporarily being committed into the code and causing leaks, train developers to follow secure coding practices or use a code vulnerability scanning tool. 

2. Misconfigured Access permissions

Another common Git security issue is misconfigured access permissions. Git is distributive, meaning it doesn't have native, granular access control. As a result, Git users gravitate towards Git repo hosts like GitHub or Bitbucket. It's because they offer granular access controls with multiple layers, including:

• Making repositories entirely public or private
• Providing more user permissions like administrating, reading, and writing
• Granting people outside the organization access to a specific repo 

Misconfigured Access permissions jeopardize your Git repositories; therefore, following the access permission best practices is recommended. While there are many, you should implement the following best practices at a minimum:

• Ensure that your Git repositories are private whenever possible.

Resmo notifies you in real-time when a Git repo visibility changes from private to public. What’s more, you can easily query repository configurations and quickly detect anomalies.

Related query in Resmo
SELECT recordedAt, before.full_name, before.private AS "before", after.private AS "after" FROM github_repo_changes WHERE 'private' IN fields

• Users should have access to only what's necessary for them. This minimizes the mistakes and risks.
• Review and remove inactive users periodically. 
• Ensure that 2FA is enabled for an extra layer of protection. 

With Resmo, you can query if 2FA is enabled for your organization’s GitHub, GitLab, and Bitbucket accounts.

Related query in Resmo
SELECT id, name, twoFactorRequirementEnabled FROM github_org WHERE twoFactorRequirementEnabled = true

3. Ignoring .gitignore

The .gitignore file allows you to specify files that you intentionally want Git to ignore. Git won't check or include the files listed in the .gitignore file. Developers should be cautious when using the .gitignore feature as some may not be correctly trained on how to use it. For example, a developer might add a ".gitignore" to a folder name, assuming Git would ignore it (which is not the case at all). 

A properly used .gitignore strategy specifies which files are committed to the repository, preventing sensitive information from accidentally getting exposed.

4. Unprotected branches

As mentioned earlier, centralized Git repository hosts like GitHub enhance permission management. This is also valid when it comes to enforcing branch protection. GitHub, for example, allows you to set a branch protection rule on any branch. For each of your branch protection rule, you can enable or disable certain settings, including:

• Require status checks before merging
• Require conversation resolution before merging
• Require linear history
• Require merge queue
• Require signed commits (More details)

5. Unsigned commits

GitHub allows you to sign commits with a GPG key to reduce impersonation risks. Typically, if a user is given "write" permission to a Git repo, it means the owner trusts that the user won't commit malicious code. As a result, normal commits aren't cryptographically signed, making it easy for threat actors to impersonate. 

When committing to a Git repository, you can see the author committing. Yet, unless the author signed the commit with a GPG key, you can't trust what you see. Signed commits have a verified icon next to the commit log entry. This way, you can make sure that it's the original author.

6. Git vulnerabilities

Although known Git vulnerabilities are typically resolved quickly by the Git development team, if you're self-hosting Git, it's up to you to catch up with the latest security updates as soon as possible. Unpatched servers are easy targets for attackers since locating Git servers through web research is rather simple.

7. Unpatched software, supply-chain attacks

It would be a mistake to assume that hackers are limiting themselves to directly attacking a target. Git is typically combined with other services and tools. That's why it's more fruitful for malicious actors to execute supply-chain attacks on those tools and services to expose multiple entities that use them. 

To shield your organization from supply-chain attacks, apply tool-chain security patches as soon as they are released and perform regular backups. 

Securing your Git repositories with Resmo

It wouldn't be an exaggeration to say that there are dozens of best practices you can implement in your development workflow and secure your Git repositories. But, manually checking your Git assets one by one for vulnerabilities can become time-consuming, error-prone, and discontinuous. This is where Resmo steps in.

As a continuous cyber asset visibility, security, and compliance solution, Resmo provides one-click integration with the popular Git hosting services; GitHub, GitLab, and Bitbucket. With Resmo, development teams can automate security audits and focus more on shipping. 

• Consolidate and query all your assets in one place.
• Track resource changes in real-time.
• Continuously audit all resources and receive notifications on rule changes. 

Reading suggestion: Getting Started with Resmo and GitHub