Research note
Public infrastructure can expose useful evidence of service relationships. The difficult part is knowing where observation ends, where attribution begins, and what an organisation should be able to explain.
I started the ThreatScope Check Provider Catalogue for a practical reason: I wanted DNS, inbound mail and SPF observations to be easier to interpret.
A nameserver value can identify where authoritative DNS appears to be operated. An MX target can reveal part of an inbound mail route. An SPF reference can point to a service authorised to participate in sending mail for a domain. But the raw value is often much less useful to a governance reader than the service relationship it represents.
The catalogue began as a classification problem. As it matured, the more interesting questions became about evidence, ownership and change.
This note records what that work currently supports, where the evidence stops, and why I think the distinction matters for TrustSurface research.
The first boundary is the most important.
If a public record matches a documented provider-controlled infrastructure pattern, it can support a bounded service association. It does not automatically establish a commercial relationship, organisational ownership, active use, service intent or the complete dependency chain behind that record.
For example, an MX target may identify an inbound gateway without identifying the mailbox platform behind it. A nameserver can identify authoritative DNS infrastructure without identifying the registrar. An SPF reference may identify a sending service without proving that the service is actively sending mail today.
That leaves an important boundary. Public observation can establish the technical value that is visible. Provider evidence may support a bounded association with a service. Ownership still requires organisational evidence, and the reason the relationship exists requires business, architecture or procurement context.
The catalogue therefore records only the association its evidence supports. A provider or service label is useful when its boundary is explicit; it should not quietly become a statement about ownership, contract or organisational intent.
Most established organisations have more than one version of their technology estate.
Procurement has suppliers and contracts. Finance has payees. Technology may have service registers, architecture diagrams and a CMDB. Security may hold another view for third-party risk.
Public infrastructure provides a different perspective. It is incomplete, but it is independently observable.
That makes it useful as a reconciliation source rather than an authoritative inventory.
If a service association is visible in infrastructure but absent from the internal inventory, there is a question worth asking. If the organisation believes a service has been retired but an externally visible authority remains, there is a question worth asking. If a new association appears, there should be an explanation of the change that introduced it.
The outside-in view cannot replace the inside-out inventory. It can challenge it.
Internal records and observable infrastructure provide different views of the same estate. Reconciliation is useful because neither view is complete on its own.
SPF provided the clearest example.
SPF is normally discussed as an email-authentication mechanism. But its service references can also expose part of the dependency surface behind organisational sending.
Once a reference can be associated with a documented service, an opaque DNS value starts to carry operational meaning. Someone introduced that sender. Some capability presumably depends on it. Someone should own the relationship. When the service is retired, the authority should be considered as part of that retirement.
Seen this way, an SPF change is not always merely a DNS change. It may represent a change in who is authorised to act through part of the organisation's public identity.
This is why the research is relevant to EML-05 — Sender change control. The emerging proposition is not that every SPF difference represents a meaningful business event. It is that identifiable sender-service associations can provide evidence for reconciling authorised senders, ownership and service lifecycle.
The Provider Catalogue also forced a decision about uncertainty.
Some associations are directly supported by provider documentation. Others have converging evidence but still lack an important condition. Some are ambiguous. Some observations turn out not to describe a provider relationship at all.
Instead of forcing those cases into a label, the catalogue distinguishes working states including verified, indicated, withheld and unresolved.
An indicated association is deliberately stronger than a guess and deliberately weaker than a released runtime association. A withheld association records that something was investigated and that the safer result is still unresolved.
That distinction has become relevant beyond the catalogue.
Technology governance often rewards clean status: compliant or non-compliant, known or unknown, red or green. But the evidence underneath those states is rarely that neat.
A more useful question is: what do we know, how do we know it, and how confident are we in the assessment?
That sits comfortably with the existing TrustSurface distinction between a Trust Signal, the Evidence used to assess it, and the resulting assessment state. The Provider Catalogue work adds a practical reminder: useful evidence does not have to be stretched beyond the boundary it can support.
The Provider Catalogue work now gives me a clearer way to think about TP-01 — Vendor inventory and ownership.
A mature vendor inventory should not be reduced to a procurement list. Nor should an external scan be treated as proof of the vendor estate.
The more useful model is reconciliation between two evidence sets:
Declared relationships — the suppliers, services and owners known through contracts, architecture, service management and internal governance.
Observable associations — third-party infrastructure relationships that can be supported from the organisation's externally visible technical surface.
The gap between those views is where the governance questions begin.
Who owns this service? Why is it present? What authority has been delegated? How would we recognise a meaningful change? What should disappear when the service is retired?
The public evidence cannot answer all of those questions. A governed organisation should be able to.
The working pattern I am taking forward is:
observe → associate → reconcile → assign ownership → govern change
Each transition adds something the previous step could not establish.
Observation gives us the visible technical fact. Association adds a bounded interpretation supported by evidence. Reconciliation compares that interpretation with organisational knowledge. Ownership introduces accountability. Change governance deals with how the relationship is introduced, altered and retired.
This is why I am not treating the Provider Catalogue work as a reason to change the Trust Signal Catalogue immediately. It is evidence informing the framework, not proof that every externally observable association belongs in the baseline.
The next useful validation is organisational: compare observable associations with a known internal service and vendor inventory, examine the disagreements, and determine which mismatches are materially useful rather than merely technically interesting.
The Provider Catalogue started as a way to make infrastructure values easier to understand.
Its more useful contribution has been to expose the distance between seeing something and governing it.
Public infrastructure can reveal relationships. Evidence can make some of those relationships attributable. Historical observation can show when the visible surface changes. None of that, by itself, tells us whether the relationship is intentional, owned or well governed.
That remains an organisational responsibility.
For TrustSurface, the emerging proposition is simple: a trust surface includes not only the signals an organisation exposes, but the relationships those signals reveal, the confidence with which those relationships can be interpreted, and the organisation's ability to explain and govern them.
This research note draws on development and operation of the ThreatScope Check Provider Catalogue and its consumption by .au Domain Observatory. The current public release referenced here is Provider Catalogue 1.5.0: 73 provider identities and 99 active rules across DNS hosting, inbound mail and SPF reference roles.
The findings above are treated as supporting research for TrustSurface, particularly TP-01 — Vendor inventory and ownership and EML-05 — Sender change control. They do not, by publication alone, change those signals.
