GitHub and Source Code Recon for Secret Discovery

GitHub is not a place where secrets occasionally leak. It is a system designed to keep every version of every file forever, and that design decision makes credential exposure a structural problem rather than a human one. The attack surface exists because git preserves history by default. An attacker who understands that history can find what developers believed they deleted years ago. This article maps the techniques attackers use to scan repositories, commit history, and the wider orbit of exposure around them, then shows what whitebox access changes about finding those secrets before someone else does.

When a developer commits an AWS access key and then deletes it from the current branch, the key does not disappear. It remains in every prior commit, and every clone of the repository carries a full copy of that history. A simple git clone pulls the entire object store, not just the latest state of the code. Git is built this way on purpose. Version control means immutability, and immutability means that mistakes become permanent records.

The same logic extends to forks. When a developer forks a public repository, adds a hardcoded key in a commit, and then deletes the fork, the commits do not vanish. They remain reachable through the original repository's object store if you know the commit hash. Security researchers call this behavior Cross-Fork Object Reference, or CFOR. The developer believes the fork is gone. Git knows otherwise. It is a direct consequence of how git's content-addressed storage works across fork relationships.

CI/CD workflow files make the problem worse because they live exactly where credentials need to be. The YAML files in .github/workflows/ frequently hold hardcoded tokens, deploy passwords, and API keys, because automation requires those values to run. A developer who would never hardcode a password in application code will paste one into a workflow file because the deployment pipeline demands it. That file then sits in the repository history, indexed and searchable, forever.

The volume confirms the structure. GitGuardian's State of Secrets Sprawl 2026 counted tens of millions of new hardcoded secrets added to public GitHub repositories in 2025 alone, and the figure grew substantially year over year. Tooling that speeds code generation also speeds credential exposure, and that tooling is now a default part of the development workflow.

The recon toolkit attackers use to scan repositories and their history

Attackers and legitimate security researchers use a small, well-maintained set of open-source tools to automate what would otherwise be manual trawling across millions of commits. These tools split into two categories: depth-first scanners that dig into a known target, and breadth-first discovery tools that find targets worth digging into. Both are freely available, actively maintained, and documented well enough that a motivated attacker needs no special expertise to use them.

TruffleHog and Gitleaks are the depth-first workhorses. Given a specific user, repository, or organization, they traverse every commit and flag patterns that match known credential formats. TruffleHog exposes flags such as --since-commit and --max-depth, while Gitleaks exposes --log-opts, to control how far into version control history each tool scans. The secrets worth finding are in the history: the commit from 2022 where someone pasted a production database password, the branch that got merged and then reverted, the file that was deleted the day after it was committed.

GitHound works from the other direction. Before you can scan history, you need to know which repositories exist. GitHound answers that question at scale. An attacker starts with a company name or a domain and GitHound returns candidate repositories, files, and code snippets that mention it.

GitHub dorking is the manual technique underlying that automation. A dork like "uberinternal.com" or newrelic /NRAK-/ locates strings that appear nowhere except in credentials belonging to a specific company. The value of these searches is that they target what is unique. A generic API key pattern produces millions of hits. A company's internal domain narrows the field to the few repositories that actually matter.

For the deepest layers of exposure, TruffleHog's --object-discovery mode is designed to enumerate Cross Fork Object References and deleted git history, including commits from deleted forks and other hidden commits that remain in the object store. Meanwhile, git log and git fsck can surface dangling blobs and removed config files that never made it to a tagged release. These are not exotic techniques. They are standard commands documented in git's own manual, and they expose the same truth: deletion in git is a matter of pointers, not data removal.

How attackers extend recon beyond the primary repository

Limiting reconnaissance to a company's official repositories misses the majority of where its secrets actually live. The attack surface extends outward through contributor accounts, forks, training datasets, and collaboration tools. An attacker who stops at the organization's GitHub page has not begun the real work.

Contributor pivoting is the most direct extension. An engineer may reuse code snippets containing company API endpoints or internal keys in personal repositories or public forks. Even if the company's main codebase is private, employees' open-source side projects can expose credentials that authenticate against production systems. The attacker does not need access to the company's infrastructure. The snippet carries more than the solution. It carries the keys.

Cross-Fork Object Reference works the same way from a different angle. A developer forks a public repository, adds credentials in a commit, and deletes the fork. The commits remain reachable via the original repository's object store. Bug bounty researchers have recovered data from deleted forks using exactly this technique, which illustrates the point: "deleted" is not the same as "gone." Git's object store does not know about deletion. It only knows about reachability, and a commit that was once part of any fork of a repository remains reachable through the shared object graph.

LLM training data creates a secondary attack surface that outlives git itself. Truffle Security's July 2026 scan of The Stack v3, a terabyte-scale dataset of public GitHub code used to train large language models, identified hundreds of thousands of credentials that remained live against production systems. A secret committed years ago can persist not just in git history but in model training corpora. The dataset is a static snapshot, but the credentials inside it are still valid, and anyone who can query the dataset can find them. Training data does not expire when a repository is deleted or a commit is squashed.

Collaboration-tool spillover widens the field further. A substantial share of 2025 incidents originated entirely outside source code, in Slack, Jira, and Confluence, and secrets found only in those tools received disproportionately higher critical severity ratings than code-only incidents. But the point matters because it corrects a mental model. Secrets do not live only in repositories. They live wherever developers paste them, and the tools that hold those pastes are part of the same attack surface.

Why secrets stay live long after they are found — and what that means for an attacker

The danger of GitHub reconnaissance is not just that secrets are discoverable. It is that discovered secrets frequently remain valid for years, giving an attacker durable access rather than a one-time foothold. The question is not whether a credential can be found. It is how long that credential keeps working after it has been found, and the answer is longer than most organizations would believe.

Truffle Security's July 2026 validation confirmed that the median credential had been publicly accessible for years before anyone revoked it. Detection alone does not produce remediation. Knowing a secret is exposed does not make it stop working.

Each live secret, once found, typically appears in multiple shadow copies on the same machine: shell history, IDE configuration, cached tokens, build artifacts, and .env files. Most scanning tools check the canonical location and miss the rest. Rotation must account for this sprawl, and most rotation processes do not.

What does a live secret actually give an attacker? An OpenAI or Anthropic credential is immediately monetizable via inference at the credential owner's expense. These are not theoretical risks. They are direct, immediate capabilities, and they explain why attackers invest time in reconnaissance that seems labor-intensive from the outside.

Push protection does not close this gap. GitGuardian found that more than half of confirmed-live credentials fall into categories push protection does not block by default: generic database connection strings, private RSA keys, and many API key formats without recognizable prefixes. The credentials that actually remain live in the wild are the ones it does not recognize.

The Uber case is the clearest named consequence of this entire chain. A security researcher used GitHub reconnaissance techniques, including dorking and history scanning, to locate an AWS credential tied to Uber's infrastructure. That credential provided access to sensitive data, and the incident became a criminal case with legal consequences for the security professionals involved. The technical mechanics of reconnaissance connected directly to a legal outcome that CTOs and founders recognize as personal risk. This is not an abstract question of best practices. It is a matter of legal exposure, and the techniques that produced it are the same ones described in this article.

What whitebox access changes about secret discovery during a pen test

The same reconnaissance techniques, applied with full repository access in a whitebox engagement, find more and find it faster than any blackbox approach can. A whitebox pen test finds secrets that blackbox and greybox assessments structurally cannot, because git history and internal configuration files are invisible from the outside. The defender who wants to close the gap must first understand what each methodology can actually see.

The definitions matter here. Whitebox testing grants the assessor full knowledge of the target: source code, architecture diagrams, CI/CD pipelines, and internal configuration. It is sometimes called crystal box testing. Blackbox testing begins with zero internal knowledge and relies entirely on external interfaces. OWASP's testing guidance makes the practical point that source code analysis removes much of the guesswork blackbox testing must live with, and that many significant security problems are difficult to discover through penetration testing alone. Logic flaws, authorization mistakes, insecure defaults, and trust boundary errors are best found with code access.

For secret discovery specifically, whitebox scanning goes three layers deep: current code, configuration files, and full version control history. A blackbox assessor can only query the public-facing surface. They will miss anything that was committed and deleted, anything in an internal branch, and anything in a CI/CD workflow file. Those are exactly the places where the most damaging secrets live, as the earlier sections established. Blackbox testing is not a weaker version of whitebox testing for this purpose. It is a different exercise entirely, one that does not address credential exposure in version control at all.

Private repositories are the larger reservoir. GitGuardian found that a substantially higher share of private repos contained at least one hardcoded secret than public repositories. The assumption that "it's private, so it's safe" is precisely the reasoning that lets secrets persist internally for years. Self-hosted GitLab instances and Docker registries expose credentials at 3 to 4 times the rate of public GitHub. These systems are only reachable with whitebox or authenticated access, which means the highest-concentration sources of credential exposure are invisible to any external assessment.

Greybox access offers a practical middle ground. Partial credentials or a standard user account can simulate a compromised insider who has cloned internal repositories. It reaches more than blackbox but less than whitebox, making it useful for modeling real attack paths that begin with phishing or credential stuffing. The point is not that greybox is sufficient. It is that greybox shows what an attacker with a foothold can see, and whitebox shows what the organization is actually carrying. The gap between those two views is the risk that no external test can measure.

How to close the gap: detection, revocation, and continuous scanning

Fixing the secrets problem requires treating revocation and continuous scanning as the standard, not detection as a one-time exercise. The exposure lifecycle outlasts any single audit. A pen test that runs once and delivers a report leaves the organization exactly where it was before the report arrived: carrying live credentials that will remain live for years.

Detection without revocation leaves the credential working. Rotation is the only action that closes the hole, and rotation must address shadow copies too. Revocation means confirming the credential is dead at the issuer and that no active copy remains in any environment.

Push protection at commit time helps at the margin but does not block the credential categories most commonly found live in the wild. Continuous pull-request scanning catches new exposures at the point of introduction rather than weeks or months later during an annual audit. Integrating secret scanning into the CI/CD pipeline means the time-to-detection compresses to minutes rather than years. The pipeline is where secrets enter, so the pipeline is where detection belongs.

A pen test that scans full repository history, CI/CD workflow files, and contributor accounts, with whitebox access and human review of findings, produces a prioritized list of live, validated credentials, not a theoretical risk register. Each finding should be confirmed exploitable before it is reported, so the team knows which secrets are genuinely dangerous versus which patterns the scanner flagged but cannot authenticate. The deliverable is not a list of things that might be problems. It is a list of things that are problems right now, with proof.

The regulatory backstop is already forming. The techniques are documented, the tools are public, and the exposure windows are measured in years. The only remaining variable is whether the defender uses those same techniques before the attacker does.