# Supply-Chain Dependency Mapping

> Maps every external provider a domain depends on — nameservers, mail exchangers, third-party email senders (SPF), CDN and hosting networks, registrar and DKIM vendors — by reading each layer of the graph and keeping only providers whose registrable apex differs from the target’s own. Each dependency is grouped by function and the flow flags single-vendor concentration: one DNS operator, one mail provider or one hosting network is a single point of failure whose outage takes the whole function down. The mirror of Digital Infrastructure Mapping: that flow maps what an entity owns, this maps what it depends on.

*Source: https://www.whisper.security/docs/workflows/supply-chain*

---
## How it uses the graph

Traverses the DNS, email, BGP, WHOIS, physical layers of the graph, in 11 steps:

01. **Operator (atlas)** _(DNS)_ — Attributing the domain to its operator…
02. **Registrable apex** _(DNS)_ — Resolving the registrable apex (eTLD+1)…
03. **DNS providers** _(DNS)_ — Finding the external nameserver operators…
04. **Mail providers** _(email)_ — Finding the external mail exchangers…
05. **Registrar** _(WHOIS)_ — Reading the domain registrar…
06. **Hosting networks** _(BGP)_ — Mapping the networks the addresses sit on…
07. **Authorized email senders** _(email)_ — Reading the third-party SPF senders…
08. **De-CDN origin** _(BGP)_ — Peeling back any CDN front to the real origin…
09. **DKIM signing vendors** _(email)_ — Reading the DKIM signing vendors…
10. **SaaS subdomain delegations** _(BGP)_ — Grouping the subdomain estate by the network it delegates into…
11. **Physical dependency** _(physical)_ — Mapping the physical facilities the hosting networks sit in…

## Why each step runs

1. **Operator (atlas).** whisper.identify names who operates the domain itself — the vendor, its category and derived roles. It is the anchor the external dependencies hang off: everything run by a DIFFERENT apex is a supply-chain dependency.
2. **Registrable apex.** whisper.psl.tldPlusOne collapses a host to its registrable domain via the Public Suffix List — the reference apex every provider is classified against. A provider whose apex matches this is self-hosted; a provider whose apex differs is an external dependency.
3. **DNS providers.** The nameservers that answer for the domain (NAMESERVER_FOR, reverse), folded to their operator apex and kept only where that apex differs from the domain's own — the third-party managed-DNS vendors. DNS root servers are filtered. One operator answering for the whole zone is a single point of failure.
4. **Mail providers.** The mail exchangers accepting inbound mail for the domain (MAIL_FOR, reverse), folded to their operator apex and kept only where external — the mail provider (Google Workspace, Microsoft 365, …). A single mail operator handling all inbound is a concentration risk.
5. **Registrar.** The registrar the domain is registered through (HAS_REGISTRAR) — the ownership-layer dependency that controls the domain's very existence. Registrar lock and transfer-control policy live here.
6. **Hosting networks.** The networks (ASNs) that route the domain's addresses — its own IPs and a sample of its subdomains (RESOLVES_TO → ANNOUNCED_BY → ROUTES), with the ASN name and registrant org. This is the compute/CDN hosting dependency. A single dominant network is a hosting single point of failure.
7. **Authorized email senders.** The third-party senders the domain authorizes to send mail on its behalf (SPF_INCLUDE), folded to their operator apex and kept only where external — SendGrid, Zendesk, Salesforce, Mailchimp and the like. Each is a delegated-trust email-delivery dependency.
8. **De-CDN origin.** whisper.origins de-fronts a CDN to the real origin IP and ASN behind it (high-confidence origins only; the bar adapts to the score scale). The origin network is the actual hosting dependency the CDN hides — the provider the service truly runs on.
9. **DKIM signing vendors.** The vendors that DKIM-sign mail for the domain (DKIM_SIGNED_BY → VENDOR) — the cryptographic email-authentication dependency. A pattern-comprehension keeps it to one row whether or not the edge is populated.
10. **SaaS subdomain delegations.** Which external networks the subdomain estate actually delegates into: sample the resolving subdomains (CHILD_OF → RESOLVES_TO → ROUTES) and tally by ASN. Subdomains pointing into AWS, Google Cloud, Fastly, Zendesk and the like are SaaS/cloud dependencies woven through the namespace.
11. **Physical dependency.** The datacenter facilities (AS_PRESENT_AT) and internet exchanges (IX_MEMBER) the hosting networks are physically present at — the deepest supply-chain layer. Sparse: only networks with PeeringDB coverage report it.

[Open the full use-case page, with the live runner](/use-cases/infrastructure-supply-chain/supply-chain)