How do I check a repository for leaked secrets before I make it public?

Making a repository public is a one-way door. Anything that was ever committed, including a file you deleted last year, can be read by anyone who clones it. A single committed key can be found and used quickly.

So before you flip the switch, look for the usual suspects: env files, private keys, tokens in config, passwords in URLs. You can do the search with git and a few lines of shell, then ask an assistant to help you sort what you found and plan the clean-up.

What you need

• A local clone of the repository.
• A terminal. You run the commands. The assistant never touches your repository.
• A rule for yourself: mask the secret values before you paste anything into a chat. Replace each value with ***. You only need file names, line numbers and the shape of the line.

Commands to run

git ls-files | grep -Ei '(^|/)\.env|\.pem$|id_rsa|\.p12$|credentials'
git grep -nEi '(api[_-]?key|secret|token|password)[[:space:]]*[:=]'
git log --all --oneline -- .env

The first lists tracked files that look like env or key files. The second finds lines that assign something to a name like key, secret, token or password. The third shows commits that touched a file named .env, which tells you whether it is in your history. Adapt the patterns to your project.

The prompt

Paste this into a new chat, then paste the masked output of the commands.

I am about to make a git repository public. Below is masked output from a few searches (secret values replaced with ***). Work only from it. Do not guess values.

1. Sort each finding into: likely real secret, likely placeholder or test value, or unclear. Give the reason for each in one line.
2. For anything that could be real, say whether it appears to be in the current files only or also in git history.
3. Write the clean-up in this order: rotate or revoke the secret first, then remove it from the files, then deal with the history if needed, then prevent it coming back (.gitignore lines and an .env.example). Do not skip the first step.
4. List what I should check that these searches cannot see.

OUTPUT OF THE COMMANDS:
[paste here]

How to check the result

Go through the "likely real" list with the actual file open. Placeholders such as YOUR_KEY_HERE are fine. Anything that looks like a real value is not.

Follow the order. GitHub's own guidance on removing sensitive data says that if the data is a secret such as a password or token, the first step is to revoke or rotate it. Once rotated, it can no longer be used for access, and that may be enough. Rewriting history is extra work after that. Read it before you start: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository

Then add the prevention lines and commit them.

What good output looks like

This is an invented illustration of the shape. A finding reads: "File config/settings.py, line 12: a variable named api_key assigned a long string. Likely real. In current files, and the .env file also appears in history." Another reads: "README.md, line 40: password = 'changeme'. Likely placeholder."

The clean-up that follows should start with the sentence "Rotate the key in the service that issued it" and nothing else should come before it. If the plan starts with deleting the file, ask the assistant to reorder it, because deleting a file that is already in history does not make the key safe.

After you have rotated, add .env to .gitignore and commit an .env.example with names and no values. Then ask a friend to clone the repository fresh and run the same three commands. Fresh eyes on a fresh clone is the best last check before going public.

Limits

• Grep patterns find shapes, not truth. A secret with an unusual format will be missed.
• It only sees what you paste. Other branches, forks and clones, and build logs are outside it.
• Searching history deeply needs more than these three commands.
• It cannot rotate a key for you. You do that in the service that issued it.

Browse all skills in the catalog