R-GIT
GitHub code search
Built-in search across public GitHub repositories, used to spot leaked secrets and exposed config.
OVERVIEW
GitHub's code search indexes the content of public repositories, so searching for a target's domain, internal hostname naming pattern, or API key prefix can surface config files, CI scripts, or commit history where a developer accidentally committed a secret. Advanced qualifiers (org:, filename:, extension:, path:) narrow a search to a specific organization's repos or a specific file type like .env or .pem.
It's effectively OSINT against a company's own developers: a hardcoded AWS key, an internal Jenkins URL, a database connection string — all fair game if committed to a public repo, and a lead worth reporting even when it isn't found through an active scan.
USE CASES
Practical use cases
- 01
Searching org: plus keywords like password, api_key, or BEGIN PRIVATE KEY across a company's public repos.
- 02
Finding internal hostnames, IP ranges, or infrastructure names leaked in config files or scripts.
- 03
Checking whether former or current employees' personal repos reference the target's internal systems.
- 04
Tracking down old commits (via history search) where a secret was added and later removed but never rotated.
QUICK START
During recon on an organization, to check whether employees or automation have leaked secrets, internal hostnames, or credentials into public repositories.
- Identify the target's known GitHub org(s) and any employees' personal accounts worth checking.
- Search org:target-name alongside common secret-pattern keywords (key, secret, password, token).
- Narrow with filename: or extension: qualifiers to hit config files (.env, .yml, .pem) specifically.
- Verify any hit is real and current before reporting — and report it responsibly if it's a live credential.
BEFORE YOU RUN IT
What to check before running it
A found secret may already be rotated or invalid — confirm it still works (within scope and rules of engagement) before treating it as a critical finding.
Searching is passive against the target but public: anything you find is also visible to anyone else searching the same terms.
Code search coverage and ranking change over time and don't index every repo equally — a clean search result isn't proof nothing is there.