How can I make git more secure?

Git is super powerful. We use git to interact with our most important intellectual property: our source code. For a SaaS provider this source code really is the whole business. If someone steals it, your IP is gone and so, probably too is your business. So this begs the question: How do you secure your use of git?

Git was originally written by Linus Torvalds to use for the development of the Linux kernel, and most engineers that use it only use like 1% of it: git clones, pulls, pushes, checkouts, and commits.

I use git for many reasons now: First, for the ability to automatically create a local (and centralized!) copy of what I’m working on (git commit, git push). Second, for the ability to share my work with the team and let them iterate on the code themselves independently (git clone, git pull). And finally, for the ability to fall back to an earlier version of a thing I was working on (git commit, git checkout).

My team of software engineers uses git every single day to build SecureStack products. I also use git when I interact with open-source projects like MVSP or CycloneDX. Part of the power of git is you can use it for basically anything: source code, text files, binary files, zip files, DLLs, and a whole more. But the real power of git is felt when an engineering team is building and collaborating together to create software. It’s pretty amazing!

Unfortunately, git famously can be difficult when something goes wrong, or when you use it in a way that it wasn’t intended (like as a backup). So there are definitely some gotchas that I learned along the way, that I am going to share with you now. Enjoy!

10. Sign your commits!

Git keeps track of who you are via your email address. Unfortunately, when Linus Torvalds wrote git he didn’t really grasp how insecure that was. It is trivially easy to “spoof” a commit by simply using someone else’s email address when committing.

Not signing commits means that someone can spoof some code and if that code isn’t reviewed well enough, well, it might just end up in production. You can see in the image next to this what a verified signed commit looks like.

BTW, Linus Torvalds was pranked recently by someone who made commits as him to the Linux kernel! Luckily, in this case, it was just a prank and the one-line commit simply said “I am Satoshi”. Imagine, however if malicious code got into the Linux kernel via commit spoofing!

Talk about software supply chain risk. That’s some serious risk right there! How many millions of servers around the world could be affected?!

9. Don’t upload your .git directory with your web content

Many developers deploy website changes or content via git. We did this for years when we built our website with static HTML and we could simply commit changes to a git repository. Unfortunately, many people that do this don’t realize they are exposing their .git directory and all its contents with each deployment. If your webserver allows directory listing then anyone that goes to https://example.com/.git/ will be able to see all of the git contents including the config file. The URL for your git repo will be in that file and anyone that is handy with git will be able to download your git repo and dredge it for username/password credentials, database names or any other sensitive data you’ve saved in the past.

8. Don’t use git as a backup!

I’ve seen a number of companies use git as a backup rather than as it was intended to be which is a concurrent versioning system. What makes git really awesome is its ability to track changes across files and allow multiple developers to interact with those changes and that collaboration. what git is not good at is backing up your mac or your Windows box. There are other tools like Crashplan, Dropbox, or Google Drive to do exactly this.

Even worse than using git for something that it’s not good for is then leaving those backups as public repositories. The amount of detail around your life and behaviors that criminals can find in these backups is huge. Passwords, aliases, rc files, etc are all easily minable from backups like this. My suggestion is you don’t use git in this way period, as its too easy to forget about it and therefore leaving yourself exposed.

7. Don’t store secrets in git repos

All developers have at some time thought it was perfectly acceptable to store credentials in a .env or config file. It’s just something you do because no one tells you not to, and no one shows you a better way to do it. And, to be fair it’s definitely a lot more complicated to use a secret store or key store to hold your sensitive credentials and application config details, than it is to simply put them in a local file and source that file. But then at some point all developers will accidentally add that file to a gir repo and push to a centralized location and then the credentials go out with it and are distributed to everyone that pulls or looks at that code. Then when the team finally notices and understands the problem, they have to go *fix* the problem! That means changing the credentials (hopefully!) but beyond that it means that the team as a group has to do agree a solution and then follow through and use something like a secret store.

6. Upgrade your git!

Many developers using a mac don’t realize that the version of git they are using is probably old. Most git installs on Apple devices come from the Xcode package and typically are two or more years old. For example, until I installed git from brew I was using the most recent version of git via Xcode which was 2.24.3 which can out in late 2019!

You can find the most recent version of git at https://git-scm.com/download/

5. Create a .gitignore file

As you are working on code you will want to make sure that your changes are being tracked. The first step in doing this is to use a git add . command. When you use the period as a wildcard you add anything in the working directory to that git repository. And this is where many engineers create problems for themselves, without even knowing it! Perhaps you had a .env file in that local directory that included all the usernames and passwords and connection strings for your app. When you do your git add . you are adding that .env file to the repository, or any other config files that include sensitive data in them.

And it’s not just about making sure that sensitive data doesn’t get committed to your repository, it’s also about saving space and lots of time. As an example, when working with javascript code it’s really common to add the whole ./node_modules directory into the repository. Same with the package-lock.json. These files and directories are NOT necessary and don’t need to be included in the repo. When you do a npm build or run yarn these files will get created at build time so you don’t have to add them.

Create a local .gitignore file and add the appropriate exclusions there. You can get a list of customized exclusions from https://github.com/github/gitignore

gitignore.io creates easy gitignore files

4. Use git hooks to automate tests

Most developers don’t realize that every git repo comes with a pre-configured set of git “hooks” that allow them to automate parts of their continuous integration workflows. If you look in the .git/hooks/ directory of your git repo you’ll see 12 files by default. Of those, the most powerful and best one to use for this purpose is the pre-commit git hook. These git hooks are just scripts so you can drop bash commands right in. Create a new file in that directory called “pre-commit”, make sure its got execute permissions and drop your security tests directly in!

You can read more in our blog post about git hooks here.

If you like what you see, book a demo!

Book Demo!

3. Don’t make stuff public that shouldn’t be

Most of the git repos we find sensitive data in are set as publicly accessible, and they shouldn’t have been. This one is easy to do especially with GitHub where the default behavior for new repos is different depending on whether you are in an “Organization” or not. The default is to create new repos as private if you are in an org. But if you are creating a repo in your own account, the default is still public. Doh!

If you *are* going to create a public repo make sure you can ensure that no sensitive data will go into that repo. Often, what a repository starts out as isn’t what it ends up as.

Many developers I’ve talked to about this problem push back saying that you can’t get much with a git repo and to them I say, look what I found today:

DB_NAME=production
DB_USER=dbadmin
DB_PASSWORD=REDACTED
DB_HOST=ls-REDACTED.rds.amazonaws.com

That is a customer’s production database creds sitting in a .env file in their exposed .git directory. I wonder what they could do with that?!

add ssh key to scm provider like github or bitbucket

2. Use SSH keys to interact with repos

Most companies use their company email as the login to their source code management platform like GitHub or Bitbucket. Then, to make it worse, most orgs don’t enforce using MFA or the use of SSH keys, so now all the bad guys have to do is phish your engineers and get their passwords and your crown jewels are now in the hands of criminals. So, the easy fix is to enforce the use of MFA and/or SSH keys during login. Why? Because this verifies that the user is who they say they are with at least one additional factor of authentication. I would suggest you use SSH AND MFA with something like Krypt. Some organizations only require occasional multi factors, like every 30 days or similar, but to me, it makes sense to have the power of multiple factors with every push.

1. Enable MFA for your remote git server

Enabling MFA is one of the most powerful, and easy-to-implement security controls your organization can ask engineers to use. It’s crazy but very few orgs require their devs to use MFA to log into their SCM providers like GitHub or Bitbucket.

This security control does NOT get in the way of the developer doing their job and it adds a significant amount of protection around your most important asset: Your software intellectual property. If there is one thing you do today its to require that all software engineers enable MFA on their SCM providers now!