As a developer, you might discover an exposed sensitive file to a public git repository; you need to follow some crucial steps. You need only a few minutes to take care of the problem and eliminate the potential damage. Maintain a composed mind and read the following steps to be more informed. This article will guide you on how to be more alert so that this issue does not crop up in the future.
Table of Contents
You are not safe even after deleting the file or repository
You can eliminate some of the risks that someone discovers your leak after making the repository private or deciding to delete it. However, the file will still be there and can be found by anyone who wants to discover it. Git has the function of recording your history, so even after deleting the file, it will still be present in your Git history.
Revoke the secret and get rid of the risk
Your first step should be to deactivate the secret you have exposed so that no one else can take advantage of it. If the key belongs to the company you are employed with, you should immediately have a word with the senior developers there. It may seem a daunting task to tell your organization about the secrets you have leaked. But, this is the best strategy, and there exists a possibility that the company already has knowledge about this leak.
Wipe the evidence of the leak
After you revoke the secret, no one can use it now. However, having a credential looks unprofessional at times and becomes the source of worries. There are many secrets that you cannot revoke too. One example is database records. There are some credentials that you cannot be sure were fully revoked.
To remove Github secrets from the history, you have the option of either deleting your repository or making it private. To do this, go to your GitHub repository and click on settings. Scroll down to the danger and click on the “Make Private” option to obscure the repository from public view.
Another crucial step is rewriting Git history. You can use well-established tools like BFG Repo-Cleaner for this purpose. To go about this, first ensure that you have installed java. The next step is to clone your repository. After doing this, delete the sensitive file. Your latest commit on the current branch is already protected by BFG, so ensure that it is clean. Delete the “config.py” file, and you are good to go. The branches other than the current are not secured, so if you find “config.pu” on another branch, it will be mopped up by BFG.
Go through your access logs
The leakage of one access key can affect other keys and can cause the exposure of other secrets. For instance, the access key of Slack might send a bad actor access to messages that have fresh credentials and access codes. So double-check and see that there is no data that looks suspicious.