Zero exposures in the repositories they controlled — and three live credentials in accounts they did not

The short answer

Their developers were careful. Across the first thirty days of monitoring, ShadowMap found no secrets at all in the repositories the publisher controlled. The pre-commit hooks worked, the CI secret scanning worked, and the report said so in the same plain terms it used for everything else. That is the finding, not a caveat to it.

Every exposure that mattered sat outside that perimeter. One was a build-tooling repository in the personal account of a contract build engineer at one of the three studios. One was a public API collection published by a studio QA lead. One was a fork made by a developer who had left eighteen months earlier and never looked at it again. No internal control reaches any of those accounts, no audit of the publisher's own estate would list them, and no amount of care by the publisher's own engineers has any bearing on what is in them. Code written for you does not only live where you put it.

Why the existing stack could not close it

The publisher had already tried the obvious approach: search public code hosts for the company name and the four title names. That returns a firehose. Their titles have active modding communities, fan tooling, private-server projects, unofficial SDK wrappers and a long tail of tutorial repositories. Roughly 6,400 public repositories matched the keyword set in the first scan window. Almost none of them were the publisher's problem, and the few that were looked exactly like the rest from the outside.

Detection was never the difficulty. Attribution was. A repository does not announce who it belongs to, and the ones that carry real exposure are usually the ones that carry no corporate branding at all — because the person who created them did not think of them as work.

How the volume was made manageable

AI Review sorted the 6,400 matches into an investigation queue, relocating benign and likely-false-positive results to the Filtered by AI queue. Nothing was deleted: filtered findings stayed fully visible and every verdict remained reversible by an analyst. 268 matches survived to human review.

Analysts then confirmed ownership using identity rather than naming, and recorded which test made each link:

• Linked to your organisation — 68 repositories. Published under a corporate or studio account, committed from an address on the publisher's own contractor mail domain, or carrying a credential that targets the publisher's own infrastructure.
• References your organisation — 156 repositories. Fan tooling, modding utilities, scrapers and integrations that name the publisher but whose credentials appear to belong to the repository's own author. Surfaced for the publisher's judgement, explicitly not actioned on their behalf, with a request to confirm before acting.
• Dismissed — 44, with the reasoning retained.

The repository that mattered came through the middle test. A personal account, no company name anywhere in it, nothing an ownership search would ever return — but the commits were authored from an address on the contractor mail domain the publisher itself issues, and one credential in the tree pointed at a hostname inside the publisher's own registry namespace. Two independent identity signals, neither of them a name.

That is a 94:1 reduction from raw match to confirmed-linked, and a further narrowing from there: eleven distinct secrets, across six of the sixty-eight.

What was validated — and what deliberately was not

Every recovered value was masked in the report and characterised by type and length only. Each carried a first-seen date, a last-seen date, and links to both the platform record and the original source so the publisher could verify independently.

CART then tested each secret individually, and stated the result of each test in both directions:

• Three confirmed live. A build-artefact registry service token, verified by a single authenticated request returning a real HTTP 200 — not inferred from the token's format. Its scope was read across all release channels and write to one internal channel. A staging entitlement API key, live and read-only against a staging tenant. A webhook signing secret for store-receipt validation, live against the staging callback.
• Four confirmed dead. Two crash-reporting keys, an analytics write key and an expired personal access token, each tested and confirmed no longer usable. Demoted to informational, but retained with reasoning: they can no longer be used, and they still evidence that these endpoints and this access were publicly exposed.
• Four not tested. Credentials for third-party platforms — an advertising network, a store partner's OAuth client and two vendor SaaS tokens — outside the authorised scope. Every one labelled: not tested against the endpoint; verify and rotate to be safe. No validation was implied that was not performed.

The restraint was documented in the customer-facing report, not buried in a contract. One authenticated request per credential. Metadata and one artefact manifest listed to establish scope. Nothing downloaded, nothing written to the writable channel, and the recovered keys not reused to reach anything further. Every request carried an audit identifier so the publisher could reconcile the validation activity against its own registry access logs — which it did, on the second day.

The link that changed the severity

The same CI configuration file disclosed an internal hostname pattern. Correlated against Attack Surface, origin-server detection showed the staging entitlement API responding directly on its origin address. The platform team believed that environment was IP-allowlisted; the allowlist was applied at the edge, and the origin answered anyone who knew where to ask. The repository did not create that exposure. It published the address.

Alone, each piece is small: one token in someone's side project, one staging host answering on its origin. In sequence they describe a route from a public repository to an unreleased-content channel and a non-production environment that the publisher's own inventory recorded as unreachable.

What they did, and what changed

Rotation began before the takedown. The governing principle was stated once and applied to every row: an exposed credential is treated as compromised regardless of how briefly it was public. All three live credentials were rotated within 31 hours of confirmation, the write scope on the registry token was removed from the replacement, and the staging origin was moved behind the edge the same week. The repository removal request was raised through the platform and completed in four days — after the rotation, not instead of it. One low-severity item was recorded as Accepted Risk with a named owner and a review date.

The durable changes were the process ones. Secret scanning was extended into the three studios' pipelines as a contractual requirement at renewal, and the studios were onboarded into Vendor Risk Management so the next exposure has an owner before it happens. Docker Containers, Open Databases and Elasticsearch returned nothing for this customer in the review period, and the report recorded that they had looked.

For governance, the publisher now has something it could not previously produce: a dated scan window, a named session identifier, a stated attribution methodology, and a per-finding record of what was tested, what was confirmed dead, and what was deliberately left alone. When a platform holder's security review asks how external code exposure is monitored, the answer is an evidence artefact rather than an assurance.