Sixty-two squads, 109 cloud accounts, one inventory that stayed true

The answer, first

Yes — but only if the loop is driven by observation rather than declaration, and only if its output arrives where engineers already work. This group runs 62 delivery squads across eleven European and two Gulf markets. Any squad can provision a production-grade cloud account from a Terraform module in under twenty minutes without telling anyone. Every pull request raises a preview environment with public ingress. A sales engineer can stand up a prospect-branded demo instance on a wildcard domain from a Slack command. Governance was not failing because people were careless; it was failing because it asked engineers to describe what they had built, and building outran describing.

ShadowMap replaced the declaration with a measurement. Attack Surface discovery rebuilds the external inventory continuously from what actually responds when probed from outside; Cloud Sources connectors read the estate directly from the cloud providers themselves; CMDB Reconciliation diffs both against the ServiceNow record. In the first thirty days that produced 1,286 responsive external hostnames, which collapsed to 572 unique logical services — against a CMDB whose still-live entries numbered 367. Fifty-six per cent more running services than the record knew about. Ninety days later, the median time from a new external service first responding to a ticket sitting in the owning squad's own backlog was under 24 hours, and not one engineer had been asked to fill in a form.

Why what they already owned did not solve it

Three capabilities were in place, and all three had the same structural blind spot.

The internal developer portal and the ServiceNow CMDB are records of intent. They are accurate at the moment of provisioning and decay from that moment onward, because neither has access to ground truth. Reconciliation found the decay running in both directions: 173 of 540 recorded internet-facing entries no longer responded at all, inflating the compliance picture with systems that had been switched off but never retired from the register.

Cloud posture tooling covered accounts enrolled in the central organisation. Twenty-one of the group's 109 accounts, projects and subscriptions — all inherited from two acquisitions — sat outside it, and were therefore not so much unmonitored as unmonitorable.

The incumbent attack-surface product was seeded from a hand-maintained list of 34 domains. It saw what it was told about. It had never been told about the acquisitions, and it had never been told about the wildcard used by the demo fleet.

What continuous rediscovery found

Most of the 1,286 hostnames were not new risks; they were duplicate front doors, and correlation made the queue smaller rather than larger. 430 hostnames belonged to the sales demo fleet on a single wildcard, collapsing by served-content fingerprinting to three logical services — but each remained a separate front door with its own build, and 96 were running an image more than nine months old. Two had been restored from a production database snapshot and carried real consignment and contact records.

148 preview environments were publicly reachable past their fourteen-day teardown window, the oldest at 620 days. Because pull-request environments are created by automation and destroyed by convention, nobody was watching the difference.

Of the 572 unique logical services, 205 had no CMDB entry of any kind. Among them, the functions you would least want undocumented: an internal admin console for carrier onboarding, a partner tariff API, a legacy dispatch interface belonging to an acquired business, and a Kibana instance fronting operational logs.

Sixty hostnames carried the group's brand on carrier partners' infrastructure. These were surfaced as references your organisation — confirm before acting, not claimed as theirs. ShadowMap does not adjudicate ownership.

Making the volume manageable

The funnel ran 1,286 responsive hostnames → 572 unique logical services → 205 undocumented → 63 carrying strong signal → 19 surfaced for action in week one. Roughly 68:1. The signal test is stated in the report rather than applied silently: a service is surfaced if it returns real content, or if its name or certificate indicates a sensitive function. Hosts returning only edge block pages or empty bodies are filtered as noise — and counted, because a host that 404s still discloses its server version and its certificate.

Across Data Exposure, AI Review took 41 candidate secrets from public code repositories and mobile and JavaScript bundles down to 12 for investigation. The remainder moved to Filtered by AI, where they stayed visible and reviewable rather than being deleted. Exposed storage buckets: none found. Open databases: none found. Both reported explicitly, because a module that finds nothing still evidences that it looked.

What was validated, and what deliberately was not

CART tested all twelve escalated secrets and reported the result per finding, in both directions.

Six were confirmed live. The sharpest was a partner tariff API key committed to a contractor's public repository, which returned an authenticated response granting read access to the group's full carrier rate card — commercially sensitive pricing, not a theoretical exposure. Four were confirmed expired and demoted to informational, with the reasoning retained: the key can no longer be used, but it shows that an internal endpoint was publicly documented. Two were not tested at all — OAuth client secrets pointing at a payments platform operated by a third party on the group's behalf. Those carried the label not tested against the endpoint; verify and rotate, because the endpoint was outside the authorised scope. The product states which mode it is in, per finding, and never implies validation it did not perform.

One exclusion was agreed at onboarding and written into scope: the fleet device-management plane was placed out of bounds for CART entirely. Anything that can address vehicle hardware is not a target for automated validation, however non-destructive the payload. Validation was enabled progressively after four weeks of discovery, never at go-live.

The loop, and what it changed

Ownership is derived from cloud resource tags where they exist, and routed to the platform team where they do not. A discovered service becomes a Jira Service Management ticket on the squad's own board, a message in the squad's own Slack channel, and an event in Splunk for the SOC. The SLA clock starts at discovery rather than at triage, so a slow triage is visible instead of invisible. Findings move through Needs Review, Investigating, and then Accepted Risk, To Be Closed or Closed — with the accepted-risk trail being the artefact auditors actually asked for.

Within two quarters: the 173 dead CMDB entries were retired, removing the largest source of false assurance; preview environments moved behind an authenticated ingress by default, eliminating 148 public front doors in one platform change; the demo fleet was rebuilt on ephemeral, synthetic-data instances; and the two acquisitions' estates entered central inventory for the first time.

The Security Rating moved from C to B over the same period, broken out per business unit for the board. The team is explicit internally that the grade is a communication device, not the objective — the rate-card key was the finding that mattered, and it did not move the grade much at all.

What the security function gained was not control over the engineering org. It was an inventory it no longer has to ask anyone to maintain, and a defensible answer to the question its enterprise customers now put in every vendor questionnaire: how do you know your inventory is complete?