Remediate a leak on public GitHub

If you end up on this page, it is likely that you got an alert from our pro bono alerting service. Don't worry, leaks sometimes just happen... even to the best of us... This section provides a step by step guide on how to remediate a leak that occurred on public GitHub.

⚠️ What you should NOT do:

• Committing on top of the current source code version is not a solution. Bear in mind that git keeps track of the history, the secret will still be visible in previous commits.
• Only taking down the involved repository is not a correct solution. The leaked credentials will still be exposed in forks of the repository, and attackers could still access it in mirrored versions of GitHub.

✅ Step by step guide to remediate the leak

• Step 1: Revoke the exposed secret.
• Step 2: Clean the git history.
• Step 3: Inspect logs.

🔒 Step 1: Revoke the secret (~ 3 min)

Revoking the secret is the only way to ensure no attacker will access the involved service.

How to do it:

• Having been alerted by GitGuardian, you can navigate to the corresponding GitGuardian detector's documentation, all information about revocation are available in the Revoke the secret section of the selected detector.
• If you found out about the leak without GitGuardian and it is not a secret type handled by one of our detectors, have a look at the relevant provider's documentation. You can usually revoke your credentials in the same section you issued them.
• Finally, if you leaked corporate credentials or credentials you cannot revoke by yourself, we highly recommend you get in touch with your security team. It's OK to make mistakes, hiding them is often a bigger problem.

Whether you managed to revoke the credentials or not, move to step 2 to mitigate the leak and remove evidence of it.

🧹 Step 2: Clean the git history (~ 10 min)

If for any reason you could not revoke the leaked credentials, the quickest action to remove the credentials from most attackers' sight is to make the repository private. Although your credentials are probably mirrored in some other place on the internet, that's already a good way to buy you some time.

How to do it: Go under the settings section of your GitHub project and chose the change visibility button at the bottom.

For a matter of brand image, you may also want to clean the git history to remove any evidence of the leak. Bear in mind that this action is not sufficient as the secret can still be visible to attackers, either in forks of the involved repository, or on mirrored version of GitHub.

Also this is not a trivial action to conduct, be advised that rewriting git history may break contributing developers' workflow. Now that the credentials have been revoked and attackers cannot use it anymore, take time to do things properly.

How to do it:

• We recommend you use git-filter-repo, this tool helps to rewrite the history of a project in a user-friendly way. You can refer to this GitGuardian's blogpost for detailed instructions.
• Once you fixed your git history and pushed it to the remote server. Be aware that this may result in an orphan leaky commit remaining on GitHub. You can get in touch with GitHub support to permanently delete this data.

🔎 Step 3: Inspect logs (~ 5 min)

Inspecting your logs will give you a quick idea of whether the compromised credentials were used by an attacker or not, and what exactly happened there.

How to do it: If the involved provider is handled by GitGuardian's detection engine, you can look in the Check for suspicious activity section of the concerned detector's documentation. Otherwise, the API provider usually gives insights on when the credentials were last used in the settings page. If the compromised credentials are database credentials or private keys, you may want to look in relevant server logs.

🏁 Finally

Congratulations, now you should be covered. As you know mistakes can happen and GitGuardian is here for you. You just have to sign-up for free and benefit from GitGuardian's real-time alerting to be protected in the future. You can also scan your history to verify that you don't have other secrets buried in your code.

If you are more of a CLI person, you can have a look at GitGuardian shield. This CLI application can run in your local environment, or in a CI environment to detect more than 300 types of secrets.

Was this page helpful?