How to Use Gitleaks to Prevent Pushing Sensitive Info

The Danaïdes, condemned to spend eternity carrying water to a bathtub that always leaks.

We have all done it in one point of our lives. You have just implemented a shiny new feature on your public repo, you wrap up your last commit, run all the tests and push. You go to the kitchen to get a well deserved coffee, and just as you’re about to take the first sip, it dawns on you: You’ve pushed your (password | API Key | API Secret) to your public repository.

Your first instinct is to delete the sensitive info from the project and push again — which as we all know is useless, since the commit is still there in the history. The only thing to do is invalidate the exposed sensitive info and issue new ones as soon as possible, then fix the repository. Assuming you realised your mistake quick, then you will probably walk away from this unscathed. But what happens if you don’t?

The internet is full of stories about people mistakenly committing their sensitive info and suffering for it. Most of them involve malicious people stealing S3 access tokens and accruing thousands of dollars in bills. You don’t have much time after your push — in some cases, these so called hackers can fetch your keys and abuse them in less than ten minutes. But how?

Turns out scanning for sensitive info is pretty easy if you know how to use GitHub. You can literally just search for commits that contain “Remove API Key” in their message and you will see thousands upon thousands of commits that have sensitive info in the diff, plain as day. It would be trivial to write a bot that scrapes these results. There are also tools like gitrob and truffleHog that do it for you. I think it is safe to say that as soon as you push sensitive data, you should consider it compromised.

Let me tell you about gitleaks.

Gitleaks is a tool for scanning both local & remote repositories for any kind of sensitive info. It is fast, easy to use and very configurable.

To run it on a remote repository:

gitleaks --repo=https://github.com/path/to/your/repo

To run it locally:

gitleaks --repo-path=path/to/your/repo

To see more examples, visit the wiki page. For our purposes, we want to run it on our local repository before every push. Since gitleaks implements pretty consistent return codes (0 means no leaks and 1 means leaks present) this is actually very easy to do; rather than git push, we can just do:

gitleaks --repo-path=path/to/your/repo -v && git push

For those of you who don’t know bash, && lets you run a command if the previous command completed correctly. In our example here, git push will run only if there are no leaks found. We also put -v in there, to be able to see more information about any present leaks.

Here is an example of me running it on a repository with a (fake) AWS key committed:

As you can see, since gitleaks found a leak (an AWS key in keys.go), git push did not run. We are safe!

And here is an example of me running it after removing the AWS key:

Since there are no more sensitive info left, we are able push.

To make this process as streamlined as possible, it is a good idea to alias git push to our new command, since typing it out every time you’re going to push is a hassle. One way of doing it would be to create an alias, like so:

alias gl="gitleaks --repo-path=path/to/your/repo -v && git push"

This would work, however it is not optimal, since we want our command to be baked into git push. We should not have change our workflow. Therefore, a better option is creating a wrapper function around the git command:

Put this in your ~/bash_profile

Now, this is more like it! This will run gitleaks before every git push, without any kind of change in our workflow. With this approach, all git push options (such as -f and -v) will also work, since all flags and arguments are passed along. We can happily git push, knowing that our secrets are safe.

There you have it — a simple & hassle-free way of auditing your repository before every push. If you are working with a team, it is best to set this up in your CI tool (you do use a CI tool, right?). You can also set up a git hook that rejects commits if leaks are detected. Happy coding!