Keeping secrets out of public code

An API key in a public repository is one of the cheapest ways for a company to get breached. Attackers run automated tools that watch public code sites for new commits and pull out anything that looks like a credential. A cloud key pushed to a public repository can be found and used very quickly, sometimes before the developer has noticed the mistake.

The good news is that most of these leaks follow a handful of patterns, and they’re easy to catch if you look in the right places.

How secrets end up in code

In our experience, leaked secrets rarely come from carelessness about security. They come from ordinary shortcuts:

• Hard-coding during development. A developer pastes a key into the code to get something working, intending to move it to configuration later.
• Committed config files. A .env or settings file gets committed because it wasn’t in .gitignore.
• Git history. Someone notices a key, deletes it and commits the fix. The key is still in the repository’s history for anyone who looks.
• Personal accounts and side projects. An employee copies company code into a personal repository, or publishes a script that contains a work credential.
• Code shared outside version control. Snippets in public gists, paste sites, forum posts and AI chat tools.
• Logs and test data. Debug logs, test fixtures and sample requests that include real tokens.

The last three are the hardest, because they happen outside the repositories your security team watches.

Stop them before they’re committed

The cheapest leak to fix is the one that never happens.

• Keep secrets out of code entirely. Use environment variables or a secrets manager, and commit an example file with empty values instead of the real one.
• Add .env and similar files to .gitignore in every repository template, so new projects start safe.
• Run a secret scanner before each commit. Pre-commit hooks with tools such as Gitleaks catch most common key formats on the developer’s machine.
• Turn on push protection if your code host offers it. GitHub’s secret scanning can block pushes that contain known credential formats.
• Scan in your build pipeline as well, in case a hook was skipped. Our SAST scanner checks each pull request for secrets alongside other security issues.

Watch for leaks outside your repositories

Scanning your own repositories doesn’t help when the leak happens somewhere else. For that you need to watch public code sites for your company’s code and credentials: your domain names, internal hostnames, distinctive code and key formats. That’s what our Repo Leak Scanner does.

When a secret leaks, rotate it first

If you find a leaked secret, the order of steps matters.

1. Revoke or rotate the credential immediately. Assume it has already been copied. Deleting the commit doesn’t help, because the secret is already public.
2. Check what it could access, and look at the logs for use from unfamiliar locations since the time it was exposed.
3. Then clean up the code, the repository history and any copies.
4. Find out how it happened and fix the process, not just the instance.

Teams often do these in reverse order, cleaning up the code first because it feels like the fix. Every minute spent on history rewriting before rotation is a minute the key still works.

A quick check you can do today

Search your organisation’s public repositories, and your developers’ public profiles, for your company domain and the prefixes of the keys you use. It takes ten minutes and it’s one of the most useful security checks a small team can run.