GitHub Recon for Bug Bounty: Finding Leaked Secrets Responsibly

Developers push code to GitHub all day, and sometimes that code contains things it should not: API keys, database passwords, internal hostnames and config files. GitHub recon is the practice of searching public repositories for information tied to your target. Done well, it finds real issues. Done carelessly, it crosses lines you must not cross. This post is as much about how to behave as it is about what to search, because with GitHub recon the ethics are not a footnote. They are the main lesson.

Start with the rules, not the search

Before you type a single query, understand one thing: you are searching other people’s data. A leaked key in a public repo is still a live credential that protects a real system. Finding it is recon. Using it is an attack, and often a crime. The whole point of this work is to report leaks so they get fixed, not to log in with them.

So the rules come first:

• Never authenticate with a credential you find. Not once, not “just to confirm it works.” A valid-looking key in the right context is enough to report.
• Stay in scope. Only act on secrets that belong to assets the program allows you to test. Reading my post on how to read a bug bounty program’s scope and rules is the right first step.
• Report privately and promptly. A live secret is time-sensitive. Submit it through the program’s channel quickly and clearly.
• Do not clone and redistribute. Keep what you find private until it is fixed.

If you keep these in mind, everything below is safe and useful. If you ignore them, the same techniques turn into an attack.

GitHub recon: what you are actually looking for

Your goal is to find places where code or config tied to the target leaked into a public repository. That usually happens in one of three ways: an employee pushed company code to a personal account, a contractor left a repo public, or a secret got committed and then “removed” in a later commit while staying in the git history. The useful targets are:

• Hardcoded API keys, tokens and passwords.
• Config files such as .env, config.json or CI pipeline files.
• Internal hostnames, endpoints and subdomains you did not find elsewhere.
• Comments and documentation that describe internal systems.

Searching with GitHub code search

The simplest tool is GitHub’s own code search, and it is more powerful than most people use. Combine the target’s identifiers with terms that point at secrets. Search for the company domain, organisation name and product names alongside risky keywords.

"target.example" password
"target.example" api_key
org:target-org filename:.env
"target.example" AWS_SECRET_ACCESS_KEY

Work through a list of keywords methodically: password, secret, token, apikey, credentials, config, backup. Also search for internal domains and staging hostnames you collected during subdomain enumeration, since those strings often appear in leaked config even when a company name does not.

When you find a hit, read it carefully before you get excited. Many matches are fake placeholders like password = "changeme" or example values in documentation. A real leak has a value that looks genuine and context that ties it to a live system.

Checking commit history

Secrets are often “fixed” by deleting them in a new commit while leaving them in the history. On the web interface, open a repository’s commit list and look at older commits. On the command line, after cloning a public repo, you can inspect the log and diffs. Reading a public repo locally is fine; acting on what you find is where the rules apply.

Automating the search responsibly

Doing this by hand across many repositories is slow, so tools help. trufflehog and gitleaks both scan git history for strings that look like secrets. You point them at a repository and they report candidate findings.

trufflehog github --repo https://github.com/target-org/example-repo --no-verification
gitleaks detect --source ./example-repo --report-path leaks.json

One important detail: by default, trufflehog tries to verify a key by calling the provider’s API with it. That is using the credential, which is exactly what the rules above forbid. The --no-verification flag turns this off, so use it unless the program explicitly allows verification.

These tools reduce manual effort, but they do not remove your responsibility. They flag patterns, not confirmed, in-scope secrets. You still have to read each result, decide whether it is real, and confirm the asset is in scope. Treat the output as a to-do list for careful review, never as a list of things to go use.

A good habit: when a tool reports a possible secret, stop and ask three questions before doing anything else.

1. Does this value look real, or is it a placeholder?
2. Does it belong to an asset that is in scope for this program?
3. Can I describe the risk clearly without ever using the secret?

If the answer to all three is yes, write the report. If not, drop it.

Writing the report

A strong GitHub recon report does not need a working exploit. It needs to show the leak clearly and explain the impact. Include the repository URL, the file path, the commit where the secret appears, and what the secret protects. Make it easy for the team to find and rotate the credential. Do not paste the full secret in plain text if the platform offers a safer way to share it; follow the program’s guidance. Your value here is speed and clarity, not proof that you broke in.

Common mistakes

• Using the secret “to confirm.” This is the one mistake that turns recon into an attack. Never do it, and that includes automatic verification by tools.
• Reporting placeholders. Submitting api_key = "YOUR_KEY_HERE" wastes everyone’s time and hurts your reputation.
• Ignoring scope. A real secret on an out-of-scope asset is not yours to test. Note it if the program wants to know, but do not act.
• Sitting on a live leak. These are urgent. A slow report can mean real harm before the fix lands.

Tips to stay sharp

Keep a per-target keyword list and rerun it every few weeks, because new leaks appear constantly as people push new code. Pair GitHub recon with your other sources: hostnames from here feed back into your OSINT workflow, and leaked config often names endpoints worth testing. Above all, build the habit of treating every finding as something to report, not to use. That mindset is what separates a researcher from a problem.

Conclusion

GitHub recon can surface serious issues: live keys, exposed config and internal details that no scanner on the live site would ever reveal. The techniques are straightforward, from targeted code search to automated scanning with trufflehog and gitleaks. The hard part is discipline. Stay in scope, never use what you find, and report quickly and clearly. If you want to learn this properly and ask me questions as you practise, join my live online classes on bug bounty and recon.