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.

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

Delete your GitHub repository or make it private
Under repository, click "Settings"

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

Be warned that by making the repository private, it will lose all its GitHub stars! 
Hide your GitHub repository from the public
GitHub's Danger Zone

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

Delete your GitHub repository
You can push the repository 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 [] (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…

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.

Prevent Your Secrets from Being Exposed on GitHub

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.

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.


What does this mean: “GitGuardian has detected the following”?

GitGuardian is helping developers secure software development with automated secrets detection & remediation for private or public source code.
We scan public GitHub for secrets such as API keys or credentials in real-time. If you received an email from GitGuardian after committing to a public repository, it means we were able to find a secret in your code.

Don’t panic! Just click here to find the steps that will help you remediate this potential leak.

If this is a false positive, we apologize for the alert. Secrets detection is probabilistic: our algorithms achieve a tradeoff between not raising false alerts and not missing exposed credentials.

What is GitGuardian’s pricing?

You can find all pricing information on our pricing page.

Where can I find GitGuardian reviews?

Although Secrets detection is a new category, we are currently gathering vetted customer and user reviews of GitGuardian.

You can find reviews on the following sites:
Gartner Peer Insights
You can also find out what developers have to say about us and how customers such as Talend, Bokeh, Mirantis or Genesys use and benefit from GitGuardian