The services that can take everything down at once are rarely on the dependency diagram: the identity provider, DNS, the secrets manager, the CI/CD platform, the certificate authority and the logging pipeline. Business continuity maps tend to stop at applications, servers and suppliers. Security incidents, though, spread along shared identities and shared platforms, and a compromise of one of them reaches every service that trusts it. This guide shows how to build a service dependency map that includes those shared layers, how to discover dependencies from data rather than workshops, and how to use the map to size blast radius for both outages and compromises. It is for resilience leads, enterprise and security architects, and platform teams, and it goes beyond the record-keeping covered in our Asset Inventory and CMDB Security Guide.
Key takeaways
- Map trust as well as traffic. A dependency exists when a service calls another, and also when it accepts tokens, secrets, certificates or code from it.
- Shared platforms are the highest-fan-in nodes. Identity, DNS, secrets, CI/CD, PKI and logging usually support every important service, so they set the real blast radius.
- Discover from data, confirm with owners. Traces, flow logs, sign-in logs and secret access logs show dependencies that workshops miss.
- Ask two questions per node. What stops if it is unavailable, and what can an attacker reach if it is compromised; the answers differ.
- Keep the map alive. A dependency map built once for an audit is wrong within a quarter; refresh it from the same data sources on a schedule.
What a security-grade dependency map adds
Business impact analysis and the CMDB answer "what supports this service". A security-grade map also answers "what does this service trust". The UK NCSC Cyber Assessment Framework, principle A3 Asset management, asks organisations to understand everything required to deliver and support their systems, including service dependencies, and lists dependencies between assets that are not understood as an indicator of weakness. The table shows the dependency types to capture.
| Dependency type | Example | Outage effect | Compromise effect |
|---|---|---|---|
| Runtime call | Checkout calls the payment API | Checkout fails or degrades | Attacker in checkout can call payment with its identity |
| Authentication trust | Applications accept tokens from the workforce identity provider | Users and admins cannot sign in | Forged or stolen tokens are accepted everywhere that trusts the issuer |
| Secret supply | Services read database passwords from the secrets manager | Services fail on restart or rotation | All secrets readable by the compromised identity are exposed |
| Code and configuration supply | CI/CD deploys to production; GitOps controller applies manifests | No deployments or fixes | Attacker can ship code or configuration to every target |
| Name resolution | Internal and public DNS | Service discovery fails broadly | Traffic redirection, certificate issuance abuse |
| Certificate trust | Internal CA issues mTLS and server certificates | Expired or unissued certificates break connections | Attacker can impersonate any service the CA vouches for |
| Observability and security tooling | Logging pipeline, EDR, SIEM | Loss of visibility | Attacker can blind detection, or abuse agents with high privilege |
| Third-party SaaS | Support desk, CRM, collaboration | Business process stops | Data and integration tokens exposed |
The shared platforms that set blast radius
For each shared platform, record which services depend on it, through which identity, and what that identity can do. These are the nodes most often missing from continuity plans.
- Identity providers and directories: workforce and customer identity, Active Directory, cloud IAM. Map every application and workload that trusts each issuer, and the federation trusts between them. See the Identity Attack Paths Guide for the compromise view and Emergency Identity Operations When the Primary IdP Is Unavailable for the outage view.
- Secrets managers and key services: map which workloads read which paths, and which pipelines can write them. See the Secrets Management Guide.
- CI/CD and GitOps: map the deployment targets each pipeline identity can reach. The CircleCI Breach 2023 is the clearest lesson: customers were told to treat every secret stored on the platform as exposed, and those with a map of which services those secrets unlocked could rotate in order of impact instead of guessing.
- DNS: internal resolvers, public zones and the registrar account. See the DNS Security Guide.
- PKI: each issuing CA and the services that trust it. See the Enterprise PKI Design and CA Hierarchy Guide.
- Logging, EDR and management agents: agents that run with high privilege on every host are themselves a shared dependency. Supplier-side concentration is covered in the Third-Party Concentration Risk Guide.
Discovering dependencies from data
Workshops find the dependencies people remember. Data finds the rest. Combine sources, then ask service owners to confirm and explain.
| Source | Dependencies it reveals | Limits |
|---|---|---|
| Distributed tracing (for example the OpenTelemetry Collector service graph connector) | Service-to-service, messaging and database calls as client and server edges, with request and failure counts | Only instrumented services; the connector creates virtual nodes for uninstrumented peers named in span attributes; it is marked alpha |
| Network flow logs and service mesh telemetry | Who talks to whom, on which ports | No business meaning; noisy |
| Identity provider sign-in and token logs | Which applications and workloads authenticate against which issuer | Shows use, not the trust configuration |
| Secrets manager and KMS access logs | Which identities read which secrets and keys | Needs identity-to-service mapping |
| CI/CD configuration and deployment logs | Which pipelines deploy where, with which credentials | Spread across tools and repositories |
| Infrastructure as code and cloud configuration | Declared dependencies, IAM trust policies, network paths | Declared, not observed |
| DNS query logs | Names each host resolves, including external SaaS | Resolver coverage varies |
| Owner interviews and BIA | Manual workarounds, people and supplier dependencies, recovery priorities | Memory and optimism; see the Business Impact Analysis Template |
The OpenTelemetry service graph connector, for example, pairs client and server spans (and producer and consumer, and database client spans) into edges and emits metrics such as traces_service_graph_request_total and traces_service_graph_request_failed_total. That gives you an observed call graph you can join with identity and secret data.
Building the map
- Pick the scope: start with your five to ten most important business services, as ranked by your BIA.
- Define the model: nodes are services, shared platforms, identities and suppliers; edges are typed (calls, authenticates-with, reads-secret-from, deployed-by, resolves-via, trusts-CA, logs-to). A graph database or a simple edge table both work.
- Load observed edges from the sources above, keyed by stable identifiers (service name, workload identity, application ID).
- Add trust edges from configuration: identity provider application registrations, federation trusts, IAM role trust policies, CA trust stores.
- Confirm with owners: each service owner reviews their node, removes false edges and adds manual ones (people, suppliers, offline processes).
- Compute fan-in: count how many important services depend, directly or transitively, on each node. The top ten are your shared-fate list.
- Store and refresh: link nodes to CMDB records and refresh observed edges [monthly] (our recommendation), with owner review [twice a year].
Using the map: blast radius analysis
For each high fan-in node, answer both questions and record the result with the node.
- Availability blast radius: which important services stop, how fast, and whether a fallback exists. Feed this into contingency planning and recovery order.
- Compromise blast radius: which services, data and identities an attacker controlling this node could reach. For an identity provider, that is every application that accepts its tokens; for a CI/CD platform, every deployment target and every secret it holds.
- Recovery dependencies: what you need to recover this node. A common finding is circular: the identity provider is needed to sign in to the console that restores the identity provider.
- Response order: the map tells incident responders which credentials to rotate first after a shared platform compromise, and which services to check for misuse.
Decision guidance
| Finding | Option | Trade-off |
|---|---|---|
| One identity issuer trusted by everything | Separate administrative identity plane, break-glass paths, tiering | More to operate; protects recovery |
| One CI/CD identity deploys to all environments | Per-environment deployment identities and approval gates | More pipeline configuration |
| Single secrets manager path readable by many services | Per-service paths and policies | Migration effort per service |
| Recovery depends on the failed platform | Out-of-band recovery access and offline runbooks | Must be tested to stay valid |
| Small organisation, few services | Spreadsheet edge table from IdP, secrets and CI/CD exports | Manual refresh; good enough to start |
Detection and measurement
- New edges to shared platforms: a new application registered in the identity provider, a new identity reading production secrets, or a new deployment target, each without a change record.
- Unexpected use of high fan-in identities: CI/CD or secrets manager identities used from new locations.
- Drift between observed and recorded edges: observed dependencies not in the map are an inventory finding.
Metrics:
- Percentage of important services with an owner-confirmed dependency map.
- Percentage of map edges sourced from observed data rather than interviews.
- Number of shared platforms with a documented compromise blast radius and a rotation order.
- Number of circular recovery dependencies open.
- Age of the oldest refresh across mapped services.
Framework mapping
| Activity | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ATT&CK technique the map helps contain |
|---|---|---|---|
| Inventory of components and dependencies | CM-8 | ID.AM-03 | T1199 Trusted Relationship |
| Criticality and fan-in ranking | RA-9, CP-2(8) | ID.AM-05 | T1606.002 SAML Tokens |
| Contingency and recovery order | CP-2 | PR.IR-03 | T1484.002 Trust Modification |
| Supplier and SaaS dependencies | SA-9 | GV.SC-04 | T1195.002 Compromise Software Supply Chain |
| Risk assessment using the map | RA-3 | ID.AM-05 | T1199 Trusted Relationship |
NIST IR 8179, Criticality Analysis Process Model (final, April 2018), describes a structured way to rank systems and components by importance and the harm their loss would cause, which fits the fan-in ranking step.
Common failure patterns
- Maps that stop at the application tier: identity, DNS, secrets and CI/CD appear as "infrastructure" and are never analysed as dependencies.
- Availability-only thinking: the map is used for disaster recovery, never to ask what a compromise would reach.
- Workshop-only discovery: owners forget batch jobs, shared service accounts and SaaS integrations that data would show.
- Circular recovery: the restore runbook needs the platform being restored.
- Static diagrams: drawn once for an audit and stale within months.
- No rotation order: after a shared platform compromise, teams rotate secrets alphabetically instead of by impact.
Practitioner checklist
- Choose the top business services and map their runtime, trust, secret, deployment, DNS, PKI and logging dependencies.
- Load observed edges from tracing, flow, identity, secrets and CI/CD logs.
- Add trust edges from identity provider registrations, federation and IAM trust policies.
- Have each service owner confirm their node and add manual dependencies.
- Rank nodes by fan-in and name the shared-fate list.
- Record availability and compromise blast radius, plus a credential rotation order, for each shared platform.
- Find and break circular recovery dependencies, and test out-of-band recovery.
- Refresh observed edges on a schedule and alert on new edges to shared platforms.
Standards and references
- NCSC: Cyber Assessment Framework principle A3 Asset management
- NIST: IR 8179 Criticality Analysis Process Model
- NIST: SP 800-34 Rev. 1 Contingency Planning Guide for Federal Information Systems
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- OpenTelemetry: Service graph connector
Related NHI Mgmt Group resources: Asset Inventory and CMDB Security Guide, Third-Party Concentration Risk Guide, Identity Attack Paths Guide, Database Links and Linked Servers.