How to remediate sensitive data leaks such as API keys hardcoded in source code?

Public exposure of secrets is a fight against time. Revoking the leaked credential as soon as possible is the first priority. Taking down the repository from public GitHub is often an afterthought: it is most of the time a matter of brand reputation.

Just taking down the repository without revoking the credential won’t prevent hackers from abusing it, as GitHub is mirrored in real-time in multiple places.

There are cases however where taking down the repository as soon as possible is also very important. This is the case for credentials no one can guarantee they were properly revoked, such as SSH keys or passwords, that might be used and reused in many different places.

When trying to delete the secret from GitHub, keep the git history in mind. Simply committing on top of the actual source code to make a deletion won’t be enough as the secret will still be visible in the git history. You must rewrite the whole history of the project instead.

---

How to remediate secrets exposed in a private repository?

Every time a secret reaches centralized version control, it must be considered compromised. At this point, depending on the size of your organization, remediating is often a shared responsibility between Development, Operations and Application Security teams.

Indeed, you might need some special rights and approval to revoke the secret, some secrets might be harder to revoke than others, plus you must make sure that the secret is properly rotated and redistributed without impacting your running systems and disturbing your software development workflow.

Apart from that, depending on your organization’s policies, you might want to clean your git history as well. This will require a `git push --force`, which comes with some risks, so there is definitely a tradeoff to consider, with no correct answer!

---

How to rewrite the git history and remove sensitive data from git?

Before jumping in, be advised that rewriting .git history is not a trivial act, especially if your changes have been pushed to the server and there are many developers contributing to your repository. In this case, you will either have to completely delete the repository then push the cleaned version back, or `git push --force` to your initial repository. This is something that should be done with a senior developer, since you’ll completely break other contributing developers’ workflow and you risk accidentally deleting legitimate data.

If you want to remove the very last commit you have done, this is possible using the `git reset` command which will undo the last HEAD or commit you have made.

`git reset --soft -HEAD` Note the --soft flag: this makes sure that the changes in undone revisions are preserved. If you don't want to keep these changes, simply use the --hard flag

The problem becomes much more complicated when you are wanting to rewrite or remove commits that are deep within the git history. For this case we recommend using the BFG repo cleaner which is a great Open Source project aimed at removing sensitive data from your git repos. Please find detailed instructions on how to do this at our blog Exposing secrets on GitHub: What to do after leaking credentials and API keys.

---

How to deal with intellectual property leaks on GitHub?

In a nutshell: first, check if the leak contains any secrets such as API keys or passwords and to take appropriate action to quickly invalidate exposed credentials Then, try to engage a conversation directly with the user who made the code publicly available on the platform.

Unfortunately, GitHub is mirrored in real-time in many unknown places around the world, by many different actors, including malevolent ones. As is the case with any published data, you must consider that your code will be further disseminated in places that you don’t know and you cannot control.

The first step with IP leaks is to check if the leak contains any secrets such as API keys or passwords and to take appropriate action to quickly invalidate exposed credentials. Time plays a crucial role here because revoked credentials do not pose a threat if they were not abused during the time they were exposed, even if they are still publicly available.

The second step is to try to engage a conversation directly with the user who made the code publicly available on the platform. From our experience, most leaks on GitHub are unintentional, not malevolent, so explaining the issue and simply asking to hard delete the repository might be enough to reach your goal.

If the second step does not work, you can submit a DMCA takedown notice by following the GitHub procedure. Be aware however that GitHub has a policy to publish DMCA requests in a dedicated repository as they receive them, which might further attract attention to the case that you are trying to handle.