Industry · SaaS and product engineering

A merged pull request can publish a front door nobody registered.

ShadowMap rebuilds your external estate every 24 hours from a single apex domain, scans the public code surface outside your organisation account for secrets attributable to you, and — where it is safe and authorised — establishes whether what it found still opens anything. No agent, no repository connection, no seed list from the teams shipping.

“Our source of risk is our own velocity — repositories, build systems and short-lived infrastructure that outruns the inventory.”

Request an exposure snapshot How to evaluate this

app.shadowmap.com/org/acmecorp/attack-surface

24h

Full external rediscovery cycle

One apex domain

The entire input — no seed list, no scope file

CERT-In

Empanelled auditor since 2008 — Security Brigade

5–15

Active secrets found in the first 30 days

A band, not a promise. In a product company what moves you inside it is your own history rather than our method — how many years of commits there are to clear, and how much of the code was written by people who no longer have a badge. What is consistent is where the secrets sit: outside the organisation account your pipeline controls were drawn around.

The gap

Where a shipping estate outruns its own record

Four places a product company loses sight of its external surface, what makes each one specific to how software actually gets built, and where it surfaces. The limit of each method is on the row rather than under the page.

Where it escapes	Why it happens here	Where it surfaces
Repositories outside the organisation account	Push protection and native secret scanning govern the repositories you administer, and inside that boundary they work. A contractor pushing from a personal account, a fork made before somebody left, a build log attached to a public issue — none of that is yours to administer, so none of it is reachable by the controls you configured.	Data Exposure Monitoring
Public sources only. No agent, no repository connection, nothing authenticated into. That is also the honest limit of the method, read backwards: what stays private is invisible to us, and stays that way until the moment somebody makes it public.
Infrastructure that outlives the pull request	Preview and ephemeral environments are created by automation and removed by convention. Nothing that creates them was ever asked to register them, so nothing notices the ones that survive their teardown window — and from outside, a preview environment still answering is indistinguishable from production.	Attack Surface Management
Discovery keeps only what answers when probed, and the estate is rebuilt every 24 hours and diffed against the previous day. An environment that genuinely came down is recorded as no longer responding — a correction your own register cannot generate about itself.
A key that is public, well-formed and unproven	A rotated test key and a live administrator key look identical to entropy detection, so a queue graded on pattern strength files them side by side. In an organisation shipping weekly that queue only grows, and the one that matters is somewhere inside it.	Continuous Automated Red-Teaming
Testing runs where it is safe and authorised. A secret that falls outside authorised scope, or for which no safe probe exists, is filed as an exposure and never as a confirmation — the finding states which of the two it is on its face, rather than leaving you to assume.
Domains carrying your product name	A self-service product is reached by URL rather than through a branch or an account manager, so the address bar carries the whole of the trust decision. A look-alike domain serving your login page or your installer asks a customer to make that decision without any of the signals a longer sales motion would have given them, and registration is faster than any trademark process that might answer it.	Domain Monitoring
Look-alike, typosquatted and permutation domains are detected at registration and scored for intent before anything is raised. That distinction is the whole job here: a defensive registration by a reseller and a staged credential-harvesting site can share a name, and only one of them is a finding.

Repositories outside the organisation account

Why it happens here: Push protection and native secret scanning govern the repositories you administer, and inside that boundary they work. A contractor pushing from a personal account, a fork made before somebody left, a build log attached to a public issue — none of that is yours to administer, so none of it is reachable by the controls you configured.
Where it surfaces: Data Exposure Monitoring

Public sources only. No agent, no repository connection, nothing authenticated into. That is also the honest limit of the method, read backwards: what stays private is invisible to us, and stays that way until the moment somebody makes it public.

Infrastructure that outlives the pull request

Why it happens here: Preview and ephemeral environments are created by automation and removed by convention. Nothing that creates them was ever asked to register them, so nothing notices the ones that survive their teardown window — and from outside, a preview environment still answering is indistinguishable from production.
Where it surfaces: Attack Surface Management

Discovery keeps only what answers when probed, and the estate is rebuilt every 24 hours and diffed against the previous day. An environment that genuinely came down is recorded as no longer responding — a correction your own register cannot generate about itself.

A key that is public, well-formed and unproven

Why it happens here: A rotated test key and a live administrator key look identical to entropy detection, so a queue graded on pattern strength files them side by side. In an organisation shipping weekly that queue only grows, and the one that matters is somewhere inside it.
Where it surfaces: Continuous Automated Red-Teaming

Testing runs where it is safe and authorised. A secret that falls outside authorised scope, or for which no safe probe exists, is filed as an exposure and never as a confirmation — the finding states which of the two it is on its face, rather than leaving you to assume.

Domains carrying your product name

Why it happens here: A self-service product is reached by URL rather than through a branch or an account manager, so the address bar carries the whole of the trust decision. A look-alike domain serving your login page or your installer asks a customer to make that decision without any of the signals a longer sales motion would have given them, and registration is faster than any trademark process that might answer it.
Where it surfaces: Domain Monitoring

Look-alike, typosquatted and permutation domains are detected at registration and scored for intent before anything is raised. That distinction is the whole job here: a defensive registration by a reseller and a staged credential-harvesting site can share a name, and only one of them is a finding.

The number

Where five to fifteen comes from

The band above the fold covers the first thirty days of monitoring. A secrets count is trivially inflatable — a tool that counts pattern matches can report whatever figure it likes — so the derivation is the claim, and it sits here rather than in a footnote.

How the first-30-days figure is counted, and what moves you inside the band As of August 2026

The unit is a distinct active secret, deduplicated across every repository, fork, paste and indexed document it appears in. One key committed to four forks is one finding, not four.
The window is the first thirty days of monitoring, which is when historical exposure clears. Steady-state months run lower — the backlog is a one-time event and 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.
What moves a product company inside the band is its own history rather than our method: how much contractor and ex-employee code sits in personal namespaces, and how many years of commit history there are to work back through. The band is wide because that varies enormously between two companies of identical size.

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.
Anything private. No repository is connected and nothing is authenticated into, so a secret sitting in a private repository is neither counted nor found — and its absence from this figure is not evidence that it is safe.

A worked engagement

62 squads, 109 cloud accounts, one inventory that stayed true

One anonymised logistics-technology engagement, published as a representative example rather than as an average — it is not a figure to expect, and it is not combined with any other engagement on this site. The interesting part is not the size of the estate. It is that autonomy was never the thing that had to be surrendered in order to account for it.

Anonymised engagement, logistics technology

A platform organisation that had deliberately stopped centralising

How the estate was governed: 62 delivery squads owned their own deployments, their own repositories and their own cloud footprint across 109 accounts, projects and subscriptions. That was a decision rather than a drift — central provisioning had been the bottleneck and taking it out was the point of the whole operating model. What it cost was a single answer to the question of what the group actually ran, because no squad could see past its own boundary and the centre could only see what squads had chosen to register.
What outside-in discovery returned against the same estate: One apex domain was the entire input. Discovery worked outward through the public registration, naming and certificate record and kept only what answered, which meant accounts nobody had enrolled, preview environments past their teardown window and services belonging to acquired entities all arrived on the same footing as the estate the platform team already knew about. Nothing had to be declared for it to be found, and no squad had to be asked for a list.
What the squads then did with it: Ownership was derived from cloud resource tags where they existed and fell back to the platform team where they did not, so a discovered service became a ticket in the owning squad’s own board rather than a row on the centre’s spreadsheet. The inventory stopped being a quarterly reconciliation and became a daily diff — and the squads kept shipping on their own cadence, because nothing in that loop asked any of them to slow down.

The concession

The controls are real. The boundary they are drawn around is what moves.

Product companies are usually well instrumented inside their own perimeter, and it is worth saying so plainly before making an argument about what they cannot see.

Branch protection, push protection, native secret scanning, infrastructure-as-code policy and posture tooling over the accounts inside your management organisation are all genuine controls, and each governs exactly what you administer. Autonomy is what keeps moving the line they are drawn on: a squad able to open a cloud account, register a domain and publish an environment without raising a ticket is a squad able to put something outside every one of those controls before lunch, and nobody involved has done anything wrong. Which is why the difficult problem in an organisation of this shape is not detection at all. It is attribution. Establishing that a responding host, a public repository or a live key is yours, and then whose it is inside the company, is the step that turns a finding into work somebody finishes rather than a row somebody forwards. Ownership is derived from cloud resource tags where they exist and falls back to the platform team where they do not. Assets carrying your name on infrastructure you do not own — partner, reseller and integration estates a product company always has — are labelled for confirmation rather than absorbed into your count, because counting those as yours is a different kind of error from missing them, and both are errors.

The other direction

You are also somebody else’s third party

For a technology company the regulator rarely arrives directly. It arrives through a regulated customer’s supplier programme, as a question you are expected to answer with dated evidence rather than a policy document.

What you get asked	Where the obligation comes from	What produces the answer
Show us your external security posture, not your policy pack	Supplier due diligence inside your customers’ own third-party risk programmes, which increasingly score you from outside rather than take your word for it.	Security Ratings
A rating is an output, never the product — the findings underneath it are what you act on. What makes it usable in this particular conversation is that the categories, the maths and the bands that grade a vendor are the ones that grade your own estate, so a customer’s threshold and your internal target are the same number rather than two.
Have any of your engineers’ credentials turned up in a stealer log?	Access-control and breach-notification clauses in the contract, and the question that follows every publicised infostealer campaign whether or not you were in it.	Responding to leaked credentials
The answer that survives a follow-up question is not a count. It is which credentials were probed, which of them still authenticated, and which were not testable at all — stated per credential, because a reassurance that does not distinguish those three is not an answer.
A key of yours was public. What did you do, and when did you do it?	Contractual incident obligations, and the dated record an examiner asks your customer for at the point your customer is themselves examined.	Responding to an exposed secret
Getting the repository removed is not what closes this, and saying so early is better than being corrected later. Every secret in that history has to be rotated whether or not it comes down, because it has already been cloned by anyone who cared to. The artefact your customer wants is the record of when you knew and what you did about it.
What changed at your regulators this quarter, and does any of it reach us through you?	Regulated customers pass ICT third-party and supplier-monitoring obligations down the chain — DORA and NIS2 across the EU, the DPDP Act and CERT-In directions in India, MAS and APRA expectations where you sell into those markets.	Regulatory Intelligence
Programme context and a dated monitoring record, never a compliance opinion. Whether a given instrument binds your entity is a determination for your compliance function and your legal advisers, and ShadowMap does not make it — nor does it file, submit or report anything on your behalf.
How do you assess your own sub-processors?	Your fourth-party exposure is your customer’s third-party exposure, and the flow-down clause that says so arrives in the contract rather than in the questionnaire — which makes it a commitment you have already given before it is ever a question you are asked.	Third-Party Risk Management
The same outside-in methodology applied to your suppliers. What makes it answer this question specifically is that it is evidence you can date and hand over — a supplier read from this week, rather than a questionnaire they returned last year and have not been asked about since.

Show us your external security posture, not your policy pack

Where the obligation comes from: Supplier due diligence inside your customers’ own third-party risk programmes, which increasingly score you from outside rather than take your word for it.
What produces the answer: Security Ratings

A rating is an output, never the product — the findings underneath it are what you act on. What makes it usable in this particular conversation is that the categories, the maths and the bands that grade a vendor are the ones that grade your own estate, so a customer’s threshold and your internal target are the same number rather than two.

Have any of your engineers’ credentials turned up in a stealer log?

Where the obligation comes from: Access-control and breach-notification clauses in the contract, and the question that follows every publicised infostealer campaign whether or not you were in it.
What produces the answer: Responding to leaked credentials

The answer that survives a follow-up question is not a count. It is which credentials were probed, which of them still authenticated, and which were not testable at all — stated per credential, because a reassurance that does not distinguish those three is not an answer.

A key of yours was public. What did you do, and when did you do it?

Where the obligation comes from: Contractual incident obligations, and the dated record an examiner asks your customer for at the point your customer is themselves examined.
What produces the answer: Responding to an exposed secret

Getting the repository removed is not what closes this, and saying so early is better than being corrected later. Every secret in that history has to be rotated whether or not it comes down, because it has already been cloned by anyone who cared to. The artefact your customer wants is the record of when you knew and what you did about it.

What changed at your regulators this quarter, and does any of it reach us through you?

Where the obligation comes from: Regulated customers pass ICT third-party and supplier-monitoring obligations down the chain — DORA and NIS2 across the EU, the DPDP Act and CERT-In directions in India, MAS and APRA expectations where you sell into those markets.
What produces the answer: Regulatory Intelligence

Programme context and a dated monitoring record, never a compliance opinion. Whether a given instrument binds your entity is a determination for your compliance function and your legal advisers, and ShadowMap does not make it — nor does it file, submit or report anything on your behalf.

How do you assess your own sub-processors?

Where the obligation comes from: Your fourth-party exposure is your customer’s third-party exposure, and the flow-down clause that says so arrives in the contract rather than in the questionnaire — which makes it a commitment you have already given before it is ever a question you are asked.
What produces the answer: Third-Party Risk Management

The same outside-in methodology applied to your suppliers. What makes it answer this question specifically is that it is evidence you can date and hand over — a supplier read from this week, rather than a questionnaire they returned last year and have not been asked about since.

Most used in this sector

Where technology and software programmes start

Attack Surface Management

Continuous outside-in discovery of the internet-facing estate — including the origin infrastructure sitting behind your edge.

Data Exposure Monitoring

Secrets in public repositories, exposed storage and indexed documents — attributed to an owner and tested for whether they still open anything.

Continuous Automated Red-Teaming

Where it is safe and authorised, exposure is tested rather than asserted — and the evidence, the scope and the audit identifier are handed to you.

The jobs behind them

What teams in this sector actually ask us to do

Questions buyers actually ask

Before you evaluate this

We already run secret scanning in CI. What does this add?

Scope, not a better scanner. Native scanning and push protection cover the repositories inside your organisation account and do that job well — keep them. What they were never built to see is a personal namespace, a contractor account, a fork made before somebody left, or the paste site, storage container and indexed document where the same credential also lands. They also have no view of whether the key still opens anything, because that was not the question they were asked. The practical difference for a product company is how a finding is graded: by what the credential actually reaches rather than by how strong the pattern looked, with a file and line reference on the high-severity ones — and where testing was not authorised, the finding says so instead of implying a result nobody obtained.

Half of what you discover today will not exist next week. Is continuous discovery even meaningful for us?

That churn is the argument for it rather than against it. The external estate is rebuilt every 24 hours and diffed against the previous day, and the diff is the deliverable rather than the inventory — a new port on a known host is a same-day alert, and an environment that genuinely came down is recorded as no longer responding, which is a correction your own register cannot generate about itself. What the churn hides is the small proportion that was supposed to be ephemeral and was not: the preview environment past its teardown window, the account opened for a launch spike and never closed. Those are indistinguishable from production to anyone scanning you from outside, and they are precisely the ones that live long enough to matter.

Our customers’ security teams assess us. Can we use this in that conversation?

Yes, and it is one of the more common reasons technology companies buy it. You get an outside-in read of your own estate produced by the same method a customer’s vendor-risk team would run against you, plus a dated record of the monitoring itself — when an asset entered scope, what a given run covered, what was decided about a finding and by whom. That is the form an assurance question is actually answered in, and it is not a form a policy pack can take. Two boundaries belong beside that, not after it: ShadowMap produces the record and does not issue a compliance opinion, and where you need framework readiness or gap assessment done properly that is an assessment engagement, which Security Brigade runs at securitybrigade.com rather than us building a thinner version of it here.

Do you need access to our repositories, our pipeline or our cloud?

No. There is no agent, no repository connection and no read of private code, and the entire input is an apex domain. Everything works from public sources, seeded with the inventory discovery has already attributed to you, your staff address patterns and your brand terms. Cloud accounts can be read from the provider directly where you choose to connect them, and nothing in the discovery path depends on that — which is the point in an estate where the accounts you would most want covered are the ones nobody enrolled. The honest limit is the same sentence read backwards: what is private is invisible to us, and stays that way until somebody makes it public.

See what your last quarter of shipping actually published

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

Request an exposure snapshot See Pricing