Source code leaks: what a public repository actually gives an attacker

When a source code leak is reported internally, the first questions are almost always about the code. How much got out. Which branch. Whether anything proprietary is recoverable. Those are reasonable questions for a legal team and close to the wrong ones for a security team.

The code is rarely the fastest thing in a leaked repository. An attacker reading a repository that should not be public is not usually there to learn how your application works; for most commercial software, reverse-engineering a shipped artefact gets them most of the way anyway. They are there for the material that travels alongside the code and that nobody thinks of as code at all: the endpoints, the secrets and the architecture. All three are immediately operational, and none requires the attacker to understand a single function you wrote.

That distinction decides whether a code exposure programme produces work your team can do or a spreadsheet somebody files. It also explains why an organisation's first attempt at finding its own leaked source code returns thousands of results and no decisions.

What a repository gives away that is not code

Endpoints. Configuration files, CI pipeline definitions, environment templates and infrastructure-as-code all carry hostnames: internal API gateways, staging environments, admin consoles, build registries, database hosts. Most are not linked from anywhere public and will never appear in a certificate transparency log or a DNS wordlist, because their names were chosen by an engineer rather than generated by a pattern. The repository also hands over the naming convention itself, which is worth more than any single name — once an attacker knows the estate is organised as svc-<function>-<env>-int, the rest becomes enumerable by construction.

Secrets. API keys, service tokens, private keys, connection strings with the password inline, webhook signing secrets, cloud credentials, and .env files committed once and removed in a later commit but still sitting in history. That last category catches careful teams: deleting a secret from the working tree does not delete it from the repository, and any fork taken before the deletion keeps it indefinitely whatever happens upstream.

Architecture. Trust boundaries, which service authenticates to which, where input validation happens and where it is assumed to have happened already, which internal call paths treat the caller as trusted. This is not an exploit. It is the map that tells an attacker which exploit is worth attempting, and it compresses weeks of blind probing into an afternoon of targeted requests.

None of this needs to be your repository. Native secret detection on repositories you own works, and covers precisely the surface you own. The exposures that matter tend to sit outside it: a contract engineer's personal account, a fork left behind by someone who resigned eighteen months ago, sample code from a delivery project that ended three years ago. No internal control reaches those accounts and no audit of your own estate would list them.

Detection is easy. Attribution is the hard part

Searching public code hosts for your organisation's name takes about a minute and returns a firehose: news scrapers, sentiment-analysis datasets, coursework, unrelated companies with similar names, fan projects, tutorial forks. In a large enterprise that is thousands of results, almost none of them your problem. Meanwhile the repositories carrying genuine exposure frequently have no corporate branding in them at all, because the person who created them did not think of them as work.

So the question is not "does anything mention us" — trivially yes — but "which of these belongs to us, and which of those contains something live". Attribution has to run on identity signals rather than names: the commit author's address sits on a mail domain you issue, a credential in the tree targets a hostname inside your own namespace, a repository sits under an account that also holds work you commissioned. Two independent signals, neither a brand mention, is a far stronger link than a company name in a README.

The tags that turn a match into a finding

In ShadowMap, each repository match is analysed for likely ownership, contents, business relevance and risk, and returns one of four verdicts — Confirmed Exposure, Needs AI Review, Likely False Positive or Benign — with a priority score out of 1,000, a separate confidence value, plain-language reasoning, and controlled tags from a fixed vocabulary: Credentials, API Keys, Private Keys, PII, Database, Configuration, Internal Endpoints, Source Code, Data Dump, Financial Data, Documentation.

The tags do more useful work than the score. A repository tagged Source Code and Documentation is an intellectual-property conversation for legal, on a normal timetable. One tagged Private Keys and Internal Endpoints is an incident this evening. Those two can carry a similar risk rating, need entirely different people, and a queue sorted only by severity interleaves them.

Two design choices make automated triage safe to rely on. Nothing is deleted: material judged benign moves to a separate queue where it stays fully visible and auditable with its verdict, score and tags attached, and an analyst who disagrees moves it back permanently. And ShadowMap publishes no accuracy percentage for this filtering, deliberately — a single headline figure for a model applied across wildly different customer estates would be close to meaningless, and we would treat one sceptically from any vendor. The control that protects you is not a claimed hit rate; it is that every automated judgement is inspectable and reversible by your own analysts.

Does the leaked code belong to something that is running?

An endpoint in a leaked configuration file is an academic concern until you can show it resolves to a live production system that belongs to you. That step separates a code-leak feed from a code-leak finding, and it needs something a repository scanner does not have: a current, independently built picture of your external estate.

ShadowMap discovers the internet-facing estate outside-in, without prior knowledge, then compares leaked repositories against it. That discovery typically surfaces 30–60% more external assets than the organisation's own inventory records, and here the gap is the point rather than a vanity statistic. The endpoints most likely to appear in leaked configuration are exactly the ones least likely to be in the CMDB: staging environments, build infrastructure, project-specific hosts stood up by a delivery team and never registered.

The correlation runs the other way too. A configuration file discloses an internal hostname pattern; external discovery shows the corresponding staging API answering directly on its origin address, because the IP allowlist was applied at the edge and the origin answers anyone who knows where to ask. The repository did not create that exposure. It published the address.

Is the key live, and what does it open?

A string that looks like a key may be revoked, rotated, a placeholder, a test fixture, or entirely live. Its format tells you nothing about its state, and a report grading secrets by pattern confidence is grading the wrong property.

Validation in ShadowMap is contextual, controlled and non-destructive, and runs only within a scope authorised in advance. For a recovered secret that means establishing whether it authenticates at all — a single authenticated request returning a real response, not an inference from the token's shape — then characterising what it reaches: which service, read or write, which environment, what the blast radius is. Credentials found in configuration are dispositioned on the same axis used for leaked credentials: Confirmed Working, Maybe Working, Not Working, Not Tested.

That last state is the one most reports quietly lack. A key belonging to a third-party platform — an advertising network, a payment partner's OAuth client, a vendor SaaS token — sits outside the authorised scope and is not something anyone should be testing on your behalf. Labelling it not tested; verify and rotate is the honest answer. Keys confirmed dead are kept rather than discarded: they can no longer be used, but they still evidence that this endpoint and this level of access were publicly exposed.

For scale, 8–15% of surfaced exposures validate as genuinely exploitable across ShadowMap deployments, and customers typically see 5–15 active secrets surfaced in the first 30 days.

The corpus is not the queue

A search across public code hosts returns a corpus. A programme returns a queue, and the two are not the same order of magnitude. Brand names, product names, domains and internal naming conventions each match widely, and almost none of what comes back is your problem. What survives ownership attribution, automated triage and correlation against the live external estate is a small fraction of what was searched — small enough to be worked through in an afternoon rather than the analyst-months a manual read of the whole corpus would take.

The two figures above are the ones to plan against: 5–15 active secrets in the first 30 days, and 8–15% of surfaced exposures validating as genuinely exploitable. How far a corpus collapses before it reaches them varies enormously, and the variables are not flattering ones — how common the organisation's name is, how large its developer ecosystem is, how much engineering is outsourced. An organisation with a distinctive name and a small delivery ecosystem sees a much shallower reduction, and shallower is not worse: it means less noise existed to remove.

The durable changes are process ones rather than ticket ones — confirmed-working secrets rotated the same day, repositories holding proprietary source driven through takedown, and secret detection made a delivery requirement for outsourced development rather than a check performed after the fact. That is a control change caused by a finding rather than by a tool. Organisations working this way typically reach 40–60% faster time-to-action on high-severity findings — a function of the queue being workable, not of anyone working harder.

The first hour after a confirmed source code leak

1. Rotate before you request removal. A takedown is measured in days; rotation in minutes. Treat the credential as compromised regardless of how briefly it was public — you cannot prove nobody cloned the repository while it was up.
2. Establish state before you argue about severity. Live or dead changes the response, not merely the priority. A team debating the rating of an untested key is having the wrong meeting.
3. Check whether the disclosed endpoint is reachable, independently of what your inventory says. Leaked configuration routinely reveals origins believed to be behind an edge control.
4. Preserve the evidence — first-seen and last-seen dates, the platform record, the original source, and the secret masked and characterised by type. In a regulated environment someone else will ask for it.
5. Then look at your own logs. Code exposure monitoring establishes what leaked and what still authenticates; it cannot tell you whether anyone used it. Confirm the working secret here, then look for its successful use there — the same sequence that applies to leaked credentials that still work.
6. Fix the pipeline that produced it. Most of these exposures originate in accounts you do not own, so the durable fix is contractual rather than technical.

The question worth asking

Not how much of our code is out there — that number is unbounded and impossible to act on. The question is which repositories carry material that maps to something you are running, which secrets in them still authenticate, and what each of those opens.

Judge a code exposure capability by the size of the queue it hands you and the evidence attached to each row, not by the size of the corpus it searched. If you are evaluating one, ask to see a single finding, then ask how the vendor established that the leaked code belonged to a running production system. The answer to that second question is the entire product.

See what is public about your own estate. The Exposure Snapshot runs the code exposure module against a single apex domain and returns what we find, with recovered values masked. No agents, no credentials, no access to your systems. → Request an Exposure Snapshot

Related: Data exposure and code repository monitoring · External attack surface discovery · How validation works