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.
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!
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!
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:
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