01
What it is
GitHub OSINT is the practice of searching public code repositories, commit history and metadata to recover secrets, infrastructure details and organisational links that a target did not intend to expose. It answers questions casual browsing cannot: which credentials leaked into a commit, which internal hostnames appear in configuration files, and which real identity sits behind an anonymous contributor account.
Public repositories carry far more than source code. Commit history preserves every version of a file, including ones later deleted from the current branch, and GitHub indexes that history for full-text search. Investigators use this to recover API keys committed by mistake, trace an anonymous account back to a corporate email address left in a commit signature, or map the internal infrastructure a company references in its own configuration files.
The technique is used by security researchers auditing exposure, journalists tracing corporate or state-linked developer activity, and threat intelligence analysts fingerprinting infrastructure. It requires no special access: everything covered here works against public repositories with a free account.
When to use this guide
- Recovering credentials or API keys accidentally committed to a public repository
- Tracing an anonymous developer account back to a real name or employer
- Mapping the internal hostnames, endpoints and infrastructure a target references in code
- Verifying whether a claimed open-source contribution actually belongs to a named individual
- Investigating a company through the commit activity and dependencies of its engineering team
02
How do you search GitHub for OSINT?
Query the code search index directly, then pivot from any match into commit history, contributor profiles and linked accounts.
Free before paid. The following tools cover code search, secret detection and cross-repository scanning.
GitHub code search: Free with any GitHub account. Native full-text search across all public repositories, filterable by language, path and organisation. The starting point for every search in this guide.
grep.app: Free, no login required. Regex search across a large mirror of public GitHub repositories, useful when GitHub's own search misses a pattern or when working anonymously without a GitHub account.
PublicWWW: Free tier with registration. Searches source code across the wider web, not just GitHub, useful for finding the same leaked snippet republished elsewhere.
TruffleHog: Free and open source. Command-line scanner that checks a repository's full commit history for high-entropy strings and known credential patterns, including secrets removed from the current branch but still present in earlier commits.
Gitleaks: Free and open source. Similar function to TruffleHog with a different detection rule set; running both against the same repository catches more than either alone.
shhgit: Free and open source. Monitors GitHub's public event stream in near real time and flags newly committed secrets as they are pushed, useful for time-sensitive investigations.
Before you begin
Stop at the login
All tools in this guide work against public repositories with a free GitHub account or, for grep.app and PublicWWW, no account at all. A free account raises the code-search rate limit substantially over an unauthenticated session, so create one before starting a large scan.
Legal considerations
Reading and citing publicly committed code and commit metadata is standard OSINT practice. Do not use recovered credentials to access any system; possession of a leaked key does not authorise its use, and doing so moves the investigation into unauthorised access, a separate legal exposure.
The method
01
Anchor on the organisation or repository
Goal · Establish the correct scope before running any secret scan
Identify the target GitHub organisation, user, or specific repository. Use GitHub code search with the org: or repo: qualifier to confirm the account is genuinely linked to the target rather than a similarly named impersonator, checking the account creation date and any linked company profile.
02
Run a GitHub OSINT code search across the scope
Goal · Surface exposed credentials, internal hostnames and configuration data
Search for common leak patterns: api_key, secret, password, internal hostnames matching the target's known domain, and cloud provider credential formats such as AKIA for AWS keys. Combine terms with the org: or user: qualifier to stay inside scope.
03
Scan full commit history, not just the current branch
Goal · Recover secrets removed from the latest commit but still present in history
Clone the repository and run TruffleHog and Gitleaks against the full git history. A secret deleted in a later commit remains permanently retrievable through git's history unless the repository owner has rewritten history and force-pushed, which most projects never do.
04
Pivot from a contributor to a real identity
Goal · Connect an anonymous or pseudonymous account to a named individual
Check the contributor's commit author email, which is frequently a personal or corporate address even when the GitHub display name is pseudonymous. Cross-reference that email against the guide's companion email OSINT workflow, and check the account's starred repositories and organisation memberships for corroborating context.
05
Map dependencies and internal tooling
Goal · Understand the target's technology stack and internal naming conventions
Read package manifests (package.json, requirements.txt, go.mod) for dependency names and internal package registries. Internal tool names and hostnames referenced in CI configuration files (.github/workflows) often reveal infrastructure not visible from the public-facing website.
06
Check forks and archived repositories
Goal · Recover content the organisation has since deleted or made private
Search for forks of the target repository; a fork created before a repository was deleted or made private preserves its full history independently. Also check the Wayback Machine and Software Heritage archive for snapshots of repositories that no longer exist on GitHub at all.
07
Record source, commit hash and timestamp for every finding
Goal · Preserve the evidentiary chain before any content can be deleted or history rewritten
For each finding, record the exact commit hash, the file path, the author identity as it appeared at capture time, and a full-page archive capture. Commit history can be rewritten and force-pushed, silently erasing a public record, so capture is time-sensitive.
03
What false positives affect GitHub OSINT?
Code search results are easy to misread. The traps below cause the most misattribution.
Rotated or test credentials: A string matching a credential pattern may be a placeholder, a revoked test key, or an intentionally fake example used in documentation. Not every high-entropy match is a live secret.
Verifying check: Where safe and legal to do so, check whether the credential format matches an active service and whether the repository's documentation flags it as an example. Never attempt to use the credential to test validity.
Shared or template repositories: Many organisations start from a shared boilerplate or template repository, meaning code, comments and even committer names can appear identical across genuinely unrelated projects.
Verifying check: Compare the repository against known public templates for the same framework or language before treating shared code as evidence of a direct organisational link.
Commit author email is not always the actual committer: git allows any author email to be set locally at commit time with no verification. An attacker or a misconfigured CI pipeline can commit under someone else's identity.
Verifying check: Look for GitHub's "Verified" badge, which confirms the commit was signed with a key linked to the account, or corroborate the identity through a separate channel before treating a commit author field as confirmed attribution.
Deleted repository, cached search result: Search indexes and cached mirrors can continue to surface a repository or file for some time after the owner deletes or privatises it.
Verifying check: Confirm the repository is still live by visiting it directly. If it returns a 404, treat the cached result as historical only and note the discrepancy in your findings.
Chain of custody: Commit history is mutable. An owner can force-push a rewritten history that permanently removes a leaked secret from public view, so anything found during a GitHub investigation should be captured immediately and independently of GitHub's own availability.
Record the full commit hash (not the abbreviated form) alongside every finding.
Capture a full-page screenshot of the commit view, the file diff and the contributor profile.
Save the raw file content locally, not just a screenshot, so the exact text is preserved and searchable.
Submit the specific commit URL to the Wayback Machine's Save Page Now feature for an independent, timestamped archive.
Note the capture date and time in UTC alongside every saved item.
04
Go deeper
Reference cards, structured tutorials and tools for practitioners who want to build on this guide.
CARD · DIG-001
WHOIS investigation: domain name to attribution chain.
ViewDNS, SecurityTrails and crt.sh. Registrant email pivots that map infrastructure and hosting networks.
CARD · OPS-001
OPSEC for investigators: eight-step baseline.
Signal, Mullvad and ProtonMail. Device separation and session documentation to chain-of-custody standard.
Evidentiary standard
Signal & Shadow operates to the LST-001 evidentiary standard. All claims are graded against the LST-001 v1.0.3 confidence tiers (Confirmed, Corroborated, Reported, Alleged) per the canonical voice and structural specification.
About Signal & Shadow
Signal & Shadow is an independent forensic investigation and methodology practice publishing tutorials, reference cards, and forensic dossiers for working practitioners. Founded by Derek Bowler.
