Exposure · Public-source secret scanning

The repository that leaked your keys is not one you own.

Native secret scanning covers the repositories inside your organisation account, and inside that boundary it works. ShadowMap scans the public surface outside it — GitHub, GitLab, Bitbucket, storage containers, paste sites and indexed documents — for secrets and source code attributable to you, works out whose account produced them, and establishes whether the key still opens anything.

Request an exposure snapshot How to evaluate this

app.shadowmap.com/org/acmecorp/data-exposure

file:line

Reference on every high-severity finding

No agent

Public sources only — nothing installed, no repository connected

5–15

Active secrets found in the first 30 days

A band, not a promise. What is consistent is not the count but where they sit: most of them are in repositories your organisation does not administer, which is precisely why the scanner in your pipeline never saw them.

A worked case

One configuration file, six links, control of the platform that messages your customers

A real finding, redrawn with the customer removed. Every link is unremarkable on its own — which is why a scanner reporting secrets one row at a time never gets past the first, and why attribution is not enrichment applied after the find but the reason there was a find at all.

One exposed configuration file, followed to what it actually reaches
Link	Alone	In sequence
1 Config file in a public repository	One stray file among millions, in a developer's own account.	A credential sits outside the estate.
2 Attribution to the organisation	A developer's side project. Not obviously yours.	The repository is tied to the organisation.
3 The key is live	A key that may be revoked or fake.	Read, write and delete all succeed.
4 What the key reaches	A storage bucket of unknown value.	Months of customer chat logs, still being written to.
5 What sits beside it	A container name in a listing.	Secret key stores for serverless functions sit beside it.
6 Who the platform speaks as	An integration on a vendor's page.	It messages your customers from your verified channel.

One exposed configuration file, followed to what it actually reaches Link two decides the case and gets the least attention: the repository belonged to an individual developer rather than a company account, so no query built on the organisation name would ever have returned it. The key held read, write and delete over months of customer conversation logs still being written to, and over the container holding the secret key stores for the serverless functions behind the platform — writable key stores mean an attacker can be adopted by the runtime, on a platform that messages customers from the brand's own verified channel.

The number

Where five to fifteen comes from

The band above the fold is the first thirty days of monitoring, and that window almost always produces active secrets. Being precise about what is counted matters, because a tool that counts pattern matches can report whatever number it wants to.

How the first-30-days figure is counted As of August 2026

The unit is a distinct active secret — one credential, deduplicated across every repository, fork, paste and document it appears in. A single key committed to four forks is one finding, not four.
The window is the first thirty days of monitoring, which is when historical exposure is cleared. Steady-state months run considerably lower: the backlog is a one-time event, new commits are not.
Active means confirmed against the service it belongs to where testing was safe and authorised, or confirmed by the owning team on the revocation ticket. Nothing is counted as active on the strength of a pattern match.
The band is wide because what drives it is your history rather than our method: how much contractor and ex-employee code sits in personal namespaces, and how long the organisation has been shipping.

Deliberately excluded

Pattern matches that are not credentials — example keys in documentation, test fixtures and placeholder strings, which is the bulk of what raw scanner output consists of.
Secrets you already knew about and already had on a rotation plan when monitoring started.
Anything that cannot be attributed to your organisation or its people. Unattributed material is not counted for you, whatever it matched.

The gap

Secret scanning stops at your organisation boundary

GitHub, GitLab and Bitbucket all scan for secrets and can block a push that carries one. That control is real, and it governs exactly the repositories you administer. A personal account is not one of them.

A contractor pushes a configuration file from a personal account. A departing engineer forks a service into their own namespace and never deletes it. A build log carrying a bearer token gets attached to a public issue. None of that sits inside your organisation, so none of it is reachable by the controls you administer, and no amount of push protection touches it. Data exposure monitoring is the outside-in half of the same job: scan the public surface for material attributable to you, establish who owns it, and grade it by what it opens rather than by what it matched.

How a finding is graded

Severity is what the secret opens, not what the pattern matched

Entropy detection rates a rotated test key and a live cloud administrator key identically. Findings are graded by blast radius instead, and the grade is what decides where the finding lands.

Severity is what the secret opens, not what the pattern matched
State	What it means	What follows
Page	A live credential with production reach, or customer data readable at a public URL by anyone who knows it is there.	Paged, with a revocation ticket auto-created against the owning team carrying the exact file and line.
Ticket	A genuine exposure with bounded impact — a sandbox key, an internal tool answering publicly, an indexed document holding no personal data.	Routed to the owning team with the rotation steps, on the normal remediation cycle.
Digest	Attributable and worth recording, but nothing changes today: a stale internal hostname, a long-dead endpoint in an archived fork.	Weekly digest, and it stays in the record — the pattern across a quarter is the real finding.
Untested	The secret is well-formed and attributable, but probing it falls outside authorised scope, or no safe test exists for the service — so it carries no blast-radius grade, because nothing has established what it opens.	Filed as an exposure, never as a confirmation. Not every finding is validated, and this row is where we say which ones were not.

Key

Page now
Owning team, this cycle
Recorded, no action today
Your check, not ours

The surface

Where exposures actually surface, and what each method cannot see

Each public surface has its own attribution route and its own hard limit. The limit sits on the row rather than in a footnote, because a method described without its boundary is the thing that gets quoted back to us later.

Surface	What is scanned for	How it becomes yours
Public code repositories	Cloud keys, API tokens, database credentials and internal hostnames across public GitHub, GitLab and Bitbucket — pattern and entropy detection, with the commit that introduced it.	Commit metadata, author address domains, fork lineage, and the internal identifiers left in the code itself.
Public repositories only. Nothing is authenticated into and no private repository is read, which cuts both ways: a private repository accidentally made public is visible from the moment it is public, and not one minute before.
Cloud storage	Open S3, Google Cloud Storage, Azure Blob and DigitalOcean Spaces containers, plus Elasticsearch and MongoDB instances answering without authentication.	Container naming conventions, indexed content referencing your domain or staff addresses, and the account the container resolves to.
Discovery here is by public reachability. A container that requires authentication does not appear, and its absence from this surface is not evidence that it is configured correctly.
Paste sites	Pastebin, Ghostbin, deepai and similar, matched against brand terms, staff addresses, customer names and internal identifiers.	Content matching, plus whatever the paste itself discloses about where it came from.
Pastes are short-lived by design. A match is captured when it is seen, and a paste deleted an hour later is still evidence that the material was published.
Indexed documents	Filetype-scoped search across Google and Bing for PDF, XLS and DOC exposures hosted on your subdomains or referencing your customers.	Host ownership from the attributed inventory, plus document metadata — author, template, originating system.
Bounded by what a search engine has chosen to index. A document that is reachable but not indexed is out of reach of this method, and is more likely to surface through the storage or repository rows above.
Internal tools left public	Jenkins, Jira, Confluence, GitLab CE and similar, surfaced through Shodan and Censys where they answer from the public internet.	Certificate names, hostnames and the address ranges already attributed to you by discovery.
The finding is that the tool answers publicly, and what its unauthenticated surface discloses. Whether it can be authenticated into is a separate question, answered only where testing is safe and authorised.

Public code repositories

What is scanned for: Cloud keys, API tokens, database credentials and internal hostnames across public GitHub, GitLab and Bitbucket — pattern and entropy detection, with the commit that introduced it.
How it becomes yours: Commit metadata, author address domains, fork lineage, and the internal identifiers left in the code itself.

Public repositories only. Nothing is authenticated into and no private repository is read, which cuts both ways: a private repository accidentally made public is visible from the moment it is public, and not one minute before.

Cloud storage

What is scanned for: Open S3, Google Cloud Storage, Azure Blob and DigitalOcean Spaces containers, plus Elasticsearch and MongoDB instances answering without authentication.
How it becomes yours: Container naming conventions, indexed content referencing your domain or staff addresses, and the account the container resolves to.

Discovery here is by public reachability. A container that requires authentication does not appear, and its absence from this surface is not evidence that it is configured correctly.

Paste sites

What is scanned for: Pastebin, Ghostbin, deepai and similar, matched against brand terms, staff addresses, customer names and internal identifiers.
How it becomes yours: Content matching, plus whatever the paste itself discloses about where it came from.

Pastes are short-lived by design. A match is captured when it is seen, and a paste deleted an hour later is still evidence that the material was published.

Indexed documents

What is scanned for: Filetype-scoped search across Google and Bing for PDF, XLS and DOC exposures hosted on your subdomains or referencing your customers.
How it becomes yours: Host ownership from the attributed inventory, plus document metadata — author, template, originating system.

Bounded by what a search engine has chosen to index. A document that is reachable but not indexed is out of reach of this method, and is more likely to surface through the storage or repository rows above.

Internal tools left public

What is scanned for: Jenkins, Jira, Confluence, GitLab CE and similar, surfaced through Shodan and Censys where they answer from the public internet.
How it becomes yours: Certificate names, hostnames and the address ranges already attributed to you by discovery.

The finding is that the tool answers publicly, and what its unauthenticated surface discloses. Whether it can be authenticated into is a separate question, answered only where testing is safe and authorised.

Where it terminates

Two correlations, two different kinds of answer

A correlation is only worth the thing it terminates in. Correlation that ends in a higher-priority alert produces a better alert. Correlation that ends in a tested key produces an answer.

01 Repository → live inventory

Does this leaked code describe something that is actually running?

The finding on its own: A public repository carrying your internal hostnames and a service configuration. Real, attributable, and impossible to prioritise — it could be a prototype abandoned four years ago.
What the correlation asks: Do the hostnames, endpoints and service names in this repository appear in the live inventory that discovery has already found and attributed to you?
What it terminates in: A higher-priority alert with a reason attached: leaked source code that describes a running production application, rather than leaked source code in general. It is still an alert — it is a better one.

02 Exposed key → validation

Does this key still open anything, and how far does it reach?

The finding on its own: A well-formed cloud key in a public file. It may have been revoked the day it was committed, or it may be the one standing between the internet and your customer records.
What the correlation asks: Continuous Automated Red-Teaming tests it where that is safe and authorised: is it live, what does it open, and what is reachable behind it.
What it terminates in: An answer rather than a probability. Where testing was not authorised the finding says so and stays Untested, because a result we did not obtain is not one we will imply.

Where this gets sharper

Data Exposure Monitoring works from one correlated exposure model

Attack Surface Management A repository is compared against your live attack-surface endpoints to establish whether leaked code belongs to a running production application. Continuous Automated Red-Teaming An exposed key is tested — is it live, what does it open, what is the blast radius.

Questions buyers actually ask

Before you evaluate this

How is this different from the secret scanning GitHub already gives us?

It is a different scope, not a better scanner. Native scanning covers repositories inside your organisation account and does that job well — push protection, partner-pattern alerts, notification to the credential provider. What it cannot see is a personal account, a contractor namespace, a fork made before someone left, or the paste site, storage container and indexed document where the same credential also lands. It also has no view of whether the key still opens anything on your estate, because it was never built to answer that. Keep the native controls and run this outside them.

Do you need access to our repositories or our code?

No. There is no agent, no repository connection and no read of private code. Everything here works from public sources, seeded with the inventory discovery has already attributed to you, your staff address patterns and your brand terms. That is also the honest limit of the method: what is private is invisible to us, and stays that way until the moment somebody makes it public.

Our source code has been published. What can you actually tell us?

What it exposes, and who published it. A source code leak is worked as an inventory problem: every credential, internal hostname, endpoint and customer reference in the history is extracted and treated as public, the repository is compared against your live inventory to establish which of it describes something running, and live keys are tested where that is safe and authorised. A removal request is one route and it is not the one that closes the exposure — every secret in that history has to be rotated whether or not the repository comes down, because it has already been cloned by anyone who cared to.

What happens when you find a live key?

It is graded by what it opens, on the severity vocabulary this page publishes, and the grade decides the route. What is worth adding is the division of labour: ShadowMap opens the ticket and hands over the evidence; the rotation stays with the team that owns the account, and we do not use a discovered credential beyond what authorised testing needs to establish that it is live and what it reaches. If that same credential later surfaces in a stealer log, it attaches to the exposure you already have rather than opening a second, unrelated alert.

Find out which of your secrets are already public

One apex domain and your public code footprint, two business days, a written snapshot — with every finding attributed to the account that published it.

Request an exposure snapshot See Pricing