As a developer, if you have discovered that you have just exposed a sensitive file or secrets to a public git repository, there are some very important steps to follow.

What is a secret? In this document when we use the term secret, we are referring to anything used to authenticate or authorize ourselves, most common are API keys, SSH keys, database credentials, or security certificates.

The first step, breathe: in most circumstances, if you follow this guide carefully, it will only take a few minutes for you to nullify most of the potential damage. This post will go through the four steps needed to remove the risk and make sure it doesn't happen in the future.

If I delete the file or repository, then I’m safe right?

Unfortunately, no. If you make the repository private or delete the files, you can reduce the risk of someone new discovering your leak, but the reality is that it is very likely your files will still exist for those that know where to look (bug bounty hunters, or worse...). Git keeps a history of everything you do, so even if you delete the file, it will still exist in your git history. Even making the repository private, deleting your history, or even the entire repository, your secrets are still compromised.

There are easy ways to monitor secret leaks; for instance, GitHub has a public API where you can monitor every single git commit that is made. That means that anyone can (and they do) monitor this API to find leaking secrets.

Thinking Like a Hacker: Finding Source Code Leaks on GitHub

Continuing our series about potential attack scenarios, learn how a very easy configuration mistake on GitHub can lead to a major security breach.

GitGuardian Blog - Automated Secrets DetectionGuest Expert

For this reason, it is best to assume that if you have leaked a secret, it is compromised forever.

Leaking secrets in public repositories on GitHub and then removing them, is just like accidentally posting an embarrassing tweet, deleting it and just hoping no one saw it or took a screenshot.

Step 1. Revoke the secret and remove the risk

The first thing we need to do is make sure that the secret you have exposed is no longer active so no one can exploit it.

If you need specific advice on how to revoke keys, you can see instructions within our API Best Practices Document.

If this key belongs to an organization you work for, then it is important to speak to the senior developers at your organization. It can be scary to let your company know you have leaked sensitive information, particularly if it has happened on a personal repository. But honesty is the best approach: remember that mistakes can be forgiven if the problem is resolved and you genuinely care.

Don’t hope that the problem will go away - mistakes happen, and it is best to be honest and upfront.

Did you know?
Slack keys are among the rare API tokens that have the ability to auto-revoke themselves! As simple as using the auth.revoke endpoint!

Step 2. (Optional) Permanently delete all evidence of the leak

Once the secret has been revoked, it cannot be used anymore. Nonetheless, having credentials, even expired ones, could look unprofessional and raise concerns. Additionally, some secrets cannot be revoked (for example, database records), or credentials no one can guarantee were properly revoked (for example, SSH keys that can be used in many different places). While we will go through the steps of how to remove secrets from the git history, please note that this is not a trivial task, and it is advised to seek the guidance of a senior developer.

a. Either delete your repository or make it private

Should it become apparent that the entire repository had no place on public GitHub, navigate to your GitHub repository, then click

Then, all the way down to the "Danger Zone" and click "Make Private" to hide the repository from the public.

Note: if you wish to make a backup, then click on "Delete this repository." You will push it back later.

b. Rewrite the git history

Rewriting the git history can be very cumbersome, we strongly recommend that you follow the step-by-step instructions below before doing anything at the risk of messing up your team's work!

Rewriting your git history, removing files permanently - cheatsheet & guide

You know that adding secrets to your git repository [https://blog.gitguardian.com/secrets-credentials-api-git/] (even a private one) is a bad idea, because doing so risks exposing confidential information to the world. But mistakes were made, and now you need to figure out how to excise confidential…

GitGuardian Blog - Automated Secrets DetectionMackenzie Jackson

Step 3. Check your access logs!

This is very important, depending on the leaked secret. Sometimes when one access key leaks, it creates a domino effect and leads to exposing new secrets. For example, a Slack access key may give a bad actor access to messages containing new credentials and access codes, so it is very important to make sure that there is no suspicious-looking data!

Checking access logs really depends on the type of credential that was leaked. For example, AWS logs are sometimes centralized into Cloudwatch. Slack has a dedicated API endpoint that allows access to audit logs. This is probably a good time for you to reach out to your SRE or Application Security team to make sure everything’s fine!

Next Steps

So the credential has been revoked, and the repositories’ history has been cleaned. What should I do now?

Now you have had a good scare, it is the ideal time to start implementing some valuable security practices.

1. Get Protected with GitGuardian

GitGuardian detects secrets in your source code and integrates natively with GitHub, GitLab, Bitbucket, and Azure Repos. You can read more here and learn how it can benefit you as a developer.

GitGuardian is your code security platform to find and fix hardcoded secrets in your VCS, CI/CD tools, and infrastructure-as-code configurations – with GitGuardian’s code security policy engine.

If you want to shift your security left, prevent secrets leaks, and integrate GutGuardian anywhere in your software development cycle, learn how to install and use ggshield, the GitGuardian CLI:

How To Use ggshield To Avoid Hardcoded Secrets [cheat sheet included]

GitGuardian’s ggshield CLI tool can help you keep your secrets away from your repos and pipelines. Download our handy cheat sheet to quickly become proficient in our CLI tool.

GitGuardian Blog - Automated Secrets DetectionDwayne McDaniel

Want to learn what the GitGuardian platform is all about? Watch the webinar replay below:

2. Review API Best Practices

To better protect your secrets in the future, we advise that you look at our API Best practice guide. It has lots of helpful tips on how to make sure you don't accidentally leak secrets in the future.

F.A.Q.