What does your software
actually load?
Overview
What the chain is made of, and why dependency becomes leverage.
Read more 
Layers
Eight layers, eight owners, and one mostly empty column.
Read more
Control
Ownership changes without changing a line of code.
Read more
Boundary
Nine tools already in use, and where each one stops.
Read more
Mapping
Capture, resolution, attribution, and reconciliation.
Digital Supply Chain Mapping resolves the providers an application genuinely depends on, observed in its own traffic rather than taken from a vendor list, and then resolves those providers to the companies, owners, and jurisdictions behind them. It is the reliance axis of the same question Equity Chain Mapping asks about control, run against systems instead of corporate structures.
This is the method write-up. Three companion pages carry the context: what the chain is made of in the layers, how control over a piece of it moves in when control changes hands, and how far the existing standards and tools reach in the existing tools stop short of ownership.
The Fan-Out
Beyond the vendor list
The Problem
The vendor list is not the supply chain
Every organization can produce a list of its technology vendors. Almost none of those lists match what their applications actually do. The gap is rarely deception. It is that a list records decisions and an application records behavior, and the two begin drifting apart the day the contract is signed.
Code added after procurement
A vendor base approved at procurement, and a tag manager, consent tool, or marketing platform that adds to it afterwards. Code reaches production without a contract, a review, or anyone deciding that it should.
Undisclosed sub-processors
The named vendor performs the work through a party the disclosure does not name. The contract points at someone you can check; the data reaches someone you cannot see.
Infrastructure indirection
DNS, content delivery, hosting, and cloud tenancy place parties in the data path who were never anyone's vendor. Nobody procured them, so nobody reviewed them.
Inherited dependencies
A package pulled at build time carries its own dependencies, and theirs. The fourth tier arrives with the first, it arrives without a decision being taken, and nothing obliges anyone to name it.
Method
Beginning with a list can only ever test the list
So the work begins with what the system does, and the vendor list becomes one of the things under test rather than the boundary of the inquiry. The same six moves then run against every provider the evidence surfaces.
01
Capture
Record what the application actually does in a real session: every request and redirect, every script, style, media and data load, every cookie and storage write, and every payload sent outward. Evidence is captured, not inferred from a manifest.
02
Resolution
Resolve observed hosts to domains, addresses to networks and cloud tenancy, and connections to the certificates that secure them. The unit of analysis stops being the URL and becomes the operator behind it, with the ambiguity that shared and fronted infrastructure introduces recorded rather than resolved away.
03
Attribution
Resolve each operator to a company, and the company to its owners, its controllers, and the jurisdiction whose law governs the data it handles. This is where the digital chain hands over to the equity chain.
04
Reconciliation
Set the observed chain against the declared one: the sub-processor list, the data-processing agreement, the audit report, the software bill of materials, the procurement record. Divergence in either direction is a finding.
05
Recursion
Every provider surfaced is itself an application with a chain of its own. A third party is a first party to the tier beneath it, the chain runs to the nth party rather than the third, and the exposure is inherited all the way back up to you.
06
Change over time
A capture is a timestamp, not a state. One release, one tag change, one acquisition rewrites the chain without notice, so captures are repeated and compared, and what changed is read as carefully as what is there.
The Observation Axis
When the paperwork and the capture disagree, the capture is what happened
A questionnaire returns what a vendor believes, or intends, or is willing to put in writing. A capture returns what their code did. When the two disagree, the disagreement is the most valuable thing in the engagement, and it is usually not a lie. It is a tag added in a hurry, a library updated upstream, a sub-processor changed after the last review.
That is why the method does not start by asking. Observation is the primary evidence and the declarations are the claim under test. Run the other way round, the exercise can only grade the paperwork.
What observation yields is specific: which providers are contacted, in what order, under whose certificates and from which networks; what is sent to each of them and whether it carries identifiers; what executes inside the page and what it is permitted to reach; and which of the controls that would constrain any of it have actually been applied.
One source domain, resolved into more than a hundred third-party domains and hosts observed in a single session. Explore SCVue, the platform this method runs on.
The Attribution Axis
A domain is not a party
Knowing that an application loads a hundred hosts is inventory, not intelligence. The finding arrives when each host resolves to an operator, each operator to a company, and each company to the people and the jurisdiction behind it. Until then you have a list of names, and a list of names supports no decision.
Attribution is also where concentration becomes measurable. Twenty distinct vendors that resolve to the same three owners are not a diversified supply base; they are one dependency wearing twenty labels. The measure that matters is concentration against substitutability, and neither is visible at the domain layer.
It is also the point where the two methods meet. Once an operator has a company behind it, the question stops being a technical one and becomes an ownership one: layered holdings, funding lineage, influence exercised through terms rather than equity. That is Equity Chain Mapping, run against the parties this method surfaces.
Attribution continues upward, through the corporate structure behind each provider. Read Equity Chain Mapping.
Twenty contracts, four controlling parties, two jurisdictions. Concentration is invisible at the contract layer, because the contract layer does not record it.
Resolution
No single source resolves a host to a company
This is the step that decides whether any of the rest is worth having, and the one most likely to fail. Registration records are not what they were: by 2024 roughly 89% of generic top-level domains carried no identifiable registrant in public data, against about 24% before privacy rules changed. Four sources are used together instead.
Certificates
The certificate securing a connection carries an issuer, a subject, and every other name it covers. Those alternate names routinely associate hosts that share nothing else visible, and transparency logs make the issuance history for a domain a matter of public record rather than a matter of asking.
Networks and tenancy
An address belongs to an allocation, an allocation to an autonomous system, and an autonomous system to an organization. Where the network turns out to be shared cloud or delivery estate, the honest answer is the provider rather than the customer, and it is recorded as exactly that.
Naming and hosting history
Resolution history, delegation records, mail and infrastructure configuration, and the way a set of hosts moves together over time. Providers change infrastructure constantly, and the pattern of how a set of names changes is frequently more identifying than any single record within it.
Corporate records
Whatever the technical evidence yields is then taken into registries, filings, funding records, and sanctions and enforcement data. This is where a name becomes a company with owners and a governing jurisdiction, and where the work becomes the same tradecraft as Equity Chain Mapping.
Some hosts resolve only as far as the infrastructure in front of them
Content delivery networks, reverse proxies, and multi-tenant hosting mean an observed address can front an origin belonging to somebody else entirely, and no amount of technique resolves that in every case. So each attribution is recorded with the evidence supporting it and a confidence that reflects that evidence, and there is an explicit indeterminate state. A provider that could be resolved only as far as the infrastructure sitting in front of it is reported as exactly that, named, and left open as a question worth asking directly. An assessment that quietly promotes a delivery network to a supplier, or a shared address to a company, is considerably worse than one that says the chain went cold and where.
Since March 2025, knowing what your payment pages load has been mandatory
In one place the obligation is already specific. Since March 2025, PCI DSS requirements 6.4.3 and 11.6.1 have required anyone operating a payment page to hold an inventory of every script that executes on it, record a written justification for each, authorize it, and detect unauthorized change. That is a mandate to know what actually loads, enforced. It stops at the script, and says nothing about who operates the destination the script talks to, which is where this method carries on. The broader duty is arriving alongside it: Executive Order 14117, implemented as 28 CFR Part 202, requires the parties behind indirect foreign access to bulk sensitive data to be identified; Article 28 of the GDPR makes engaging a sub-processor a documented and authorized act rather than an implementation detail; DORA extends that expectation to financial entities and the subcontracting chains beneath their ICT providers, and the first critical ICT third-party providers were formally designated in late 2025, putting concentration itself under supervision; and NIS2 brings supply chain security into scope for organizations that never considered themselves technology firms. Every one of these assumes an organization can say what its applications depend on. A sub-processor that should appear in a mandated disclosure and does not is itself the finding.
Principles
Three rules decide what counts as a finding
Every organization of any size already runs third-party review, and most of it is conscientious work. These three rules are what govern the evidence here.
Evidence over attestation
Every finding traces to a captured artifact: a request, a response, a certificate, a payload. Any of them can be re-examined by someone who disagrees with the conclusion. An attestation cannot be re-examined. It can only be believed or not.
Absence is evidence
The provider that should be in the capture and is not is as informative as the one that is. A declared sub-processor never contacted, an integrity control missing exactly where the risk is highest, a disclosure list unchanged while the application plainly has changed. Each of those is a question worth asking.
Scope follows exposure, not contract
Conventional review covers the parties you have a contract with, because those are the parties you can send a questionnaire to. Exposure does not respect that boundary, and the tiers carrying the most risk are usually the ones with no relationship to you at all.
Deliverable
The work product is a map with the evidence attached to it
The work product is a mapped digital supply chain: the providers an application actually contacts, resolved to operators, companies, owners, and governing jurisdictions, with the observed chain set against the declared one and every divergence listed in both directions. Concentration and substitutability are assessed for the nodes that matter, and the evidence sits attached to each finding rather than behind it.
It is timestamped and reproducible. Every finding names the capture it came from, so the same session can be re-examined and a later capture can be compared against it to show what moved. Where a provider could not be attributed past a certain layer, that is stated plainly and the unresolved node is named, so the follow-on question has an address.
This yields indicators, not proof. A provider in an adverse jurisdiction is an exposure to weigh, not a verdict to act on, and it is presented that way, with provenance and confidence attached, so it can be argued with rather than simply believed.
Scope is stated alongside the findings. What was observed is what ran, on the paths exercised in that session. A provider reached only from a backend leaves no trace in a client session and is pursued through disclosure or a direct question instead. Routine cross-border operation is separated from exposure that actually warrants a decision, because almost every application touches several jurisdictions and treating that as a finding produces noise. An application whose observed chain matches its declared one, with no unattributed operator, is a real result and is reported as one.
Applications
The tradecraft does not change between engagements
Only the application changes, and the decision resting on it. These are the places the same work is most often commissioned.
Vendor and platform review
Before signing, and again afterwards: what the platform actually loads, who those providers resolve to, and which of them the contract never mentioned.
Disclosure and regulatory work
Sub-processor registers, data-processing agreements, and transfer assessments checked against observed behavior rather than against the last version of the register.
Data-flow assessment
Where identifiers, payloads, and telemetry actually go, which jurisdictions they cross to get there, and whose law governs them once they arrive.
Transactions
A target's technology estate read from the outside before access is granted, including the dependencies its own engineering team has never inventoried.
Content and platform integrity
Establishing which parties are in a position to affect what a publisher, campaign, or public-facing service puts in front of an audience, and whether the operator would knowingly have accepted every one of them.
Continuous monitoring
Recurring captures against the applications that matter most, where the change between them is the alert: a new provider, a changed owner, a control that disappeared.
A dependency means nothing until you know who is behind it
A single supplier is a sourcing problem if it is an ordinary commercial actor, and a material risk to the business if it is controlled by a party with an interest in your failure. Nothing about the dependency changes between those two cases. Only its meaning changes, and its meaning is a function of who is behind it. This method resolves reliance downward through the providers a system depends on. Equity Chain Mapping resolves control upward through the structures that own them.
Request a
Briefing
We walk through real-world use cases drawn from active engagements that demonstrate why supply chain integrity now requires senior-level attention and coordinated action.
Subscribe to stay informed on global supply chain integrity developments and nDiligence updates.
Copyright © 2026 nDiligence, Inc. All Rights Reserved.