Top 5 Git Security Mistakes

Necessity is often referred to as the mother of invention. So when you happen to be Linus Torvalds, a little bit of frustration can go a long way in creating something that leaves a lasting impact. 

Back in 2005, Torvalds was unsatisfied with the source control management (SCM) tools at his disposal. He complained that it simply took too long to apply patches and update the associated metadata, factors he knew could slow down the development of his Linux kernel.

With no other good free options available, Torvalds got to work on creating his own distributed source control system, eventually creating Git. In the years since then, Git has become the standard for how teams share and collaborate on code and a primary driver of the open source ecosystem. Companies offering Git solutions like GitHub and GitLab have grown to become valuable companies and essential platforms for developers. 

Git security: Getting it right

However, despite its widespread use, many are still making critical mistakes in how they use Git and compromising their security.   

In hopes of learning from the mistakes of others and not making them ourselves, we have compiled a list of the top 5 Git security mistakes along with some suggestions on how to keep your code and Git repos secure.

#1: Hardcoding sensitive data

This Git security fail is always worthy of a hard facepalm but we all have been guilty of it at some point. Hardcoding credentials or encryption keys in code is dangerous due to the fact that we are leaving sensitive info in plain text that is easy to read.

Having a code file on your desktop that holds your encryption key is bad enough but Git adds another layer of risk. When you check-in your code, that plaintext encryption key or password will now be stored in the repository. An attacker doesn’t need access to your computer to steal your credentials and encryption keys.

Using a hosted solution, like GitHub, exponentially raises the security risk because many open source repositories are public-facing, leaving your keys and credentials open to be read by anyone who comes across it.

Now we understand that the decision to leave this info out in the open comes from choosing ease of use over accessibility over security, but it does not have to be this way. 

Try using a secure key management solution like the open source Vault by HashiCorp for safely storing your sensitive data. The API allows your continuous integration (CI) processes (and code) to retrieve credentials and keys when necessary, eliminating the need for developers to interact with sensitive data at all in order to do their jobs.

#2: Ignoring .gitignore

The .gitignore file allows you to tell Git which files don’t belong in the repository. During the check-in process, Git won’t check-in the file types listed in the .gitignore file.

In the interest of ensuring Git security, developers should make good use of .gitignore to prevent sensitive data from reaching the repository. 

For example, a developer downloads a data backup from production to test a nasty bug. The backup is added to his local Git repository while he’s working. When the developer checks in his code, the file is sent to the team’s repo with everything else.

Now if the server is compromised, or the repository is a public GitHub repo, your customers’ sensitive data will be downloadable. Hello, data breach.

Be aware of the possibility that malware can attack your servers by tricking developers into checking in executable files. If possible (depending on your specific application needs), add .exe and .dll files to your .gitignore, so these attacks can’t be executed. If you can’t, check to make sure your company signs any executable files before executing them.

#3: Using unsigned commits

Git allows you to use PGP/GPG to sign commits. If you want to up your Git security game, use it.

Signed commits verify that the right developers are committing code to your repository. Errant check-ins could break your system or introduce harmful functionality, so we strongly suggest taking this extra step.

Setting up a public-key system for your team allows further protection when you’re compromised. You can revoke stolen or misplaced keys, preventing a malicious actor from committing code to your repo using the developer’s key. Once all developers have keys, set up Git to check all pull requests for signatures. 

You can sign your commit with the following command:

git commit –S –m "Signed commit message."

Then use the following command to merge pull requests while verifying signatures first:

git merge –verify-signatures

Once the process is set up, it’ll run smoothly and keep your repo safe.

#4: Leaving the front door open

Poor access control is one of the leading causes of compromised security and your Git server is not immune.

Protect your repository with the same care as any critical piece of your development infrastructure. You should assign access rights to each repository and give access only to the developers who need it. Don’t leave projects on GitHub public unless they’re truly meant to be public. Just like you shouldn’t leave an S3 open to the public, don’t leave anything on your repo that you wouldn’t want everyone to see. 

Lockdown your CI servers and give them the access they need to pull assets out of the repository and build it. Use a secure key store like Vault to provide access to your repo when a system requires it outside of the control of the developers on the project.

Be sure to double-check your configurations on access permissions since they can often be tricky and lead to mortifying Git security mistakes.

#5: Not patching

Leaving one of the biggest ones for last, failure to patch your software is probably the number one mistake that we can make when it comes to keeping Git secure. The maintainers of projects can invest the maximum effort to address all of the vulnerabilities in their code, but it is all for naught if we do not use their updates.

If you don’t want to fall behind, you should keep tabs on any other systems and plugins that interact with Git. Know what systems integrate with your Git installation and patch them too.

Stay up-to-date with new vulnerabilities as they come up. Use automation where possible to avoid the monotonous manual work of looking for them one by one. This can be particularly challenging when it comes to open source components because they are highly distributed. 

Make sure you’re patching your Git installation as quickly as possible stay ahead of those malicious hackers out there who might try to exploit a vulnerability when it becomes public. 

Don’t get bit by Git

Git is the same as any software ecosystem. You can operate it in a safe way or in an unsafe way. Knowing the common Git security mistakes in order to avoid them is an important step.  

Mr. Torvalds created an amazing SCM that works well for large and small projects alike. Don’t waste his excellent work by forgetting to secure your instance.