D3-SYSDM System Dependency Mapping: What It Models and How to Build It

When a library, platform or product inside a system turns out to be vulnerable or compromised, the first question is always "what depends on it?", and most organisations answer it slowly because nobody has modelled how their systems are built. MITRE D3FEND names the countermeasure that answers that question System Dependency Mapping (D3-SYSDM) and defines it as "System dependency mapping identifies and models the dependencies of system components on each other to carry out their function." It sits under the Model tactic as a child of System Mapping (D3-SYSM). This page explains what the technique models, which data sources feed it, how to build and maintain the model, how it feeds other D3FEND techniques and how to tell whether it is working. It is written for security architects, vulnerability management leads and supply chain risk teams.

Key takeaways

• It models construction, not traffic. D3-SYSDM records which components a named system is made of and which other systems it relies on, including the internal dependencies of pre-built products, so the model goes below the network level.
• Two inputs are needed. D3FEND's considerations point to both architecture artefacts and subject matter experts (the intended design) and external knowledge bases such as package managers (what the product actually contains).
• Critical systems first. D3FEND says dependencies of systems supporting critical organisational activities should be prioritised for supply chain risk analysis.
• No ATT&CK mappings. As of November 2026 the D3FEND page for D3-SYSDM lists no related offensive techniques. Its value is indirect: it makes scoping, vulnerability assessment and supply chain response faster and more accurate.
• Record the identity on each edge. Many system dependencies are authenticated with a service account, key or certificate; recording it turns the dependency model into a map of non-human identity blast radius.

D3-SYSDM at a glance

What D3FEND means by a system dependency

D3FEND's knowledge base article describes the method in one sentence: the organisation collects and models architectural information about the software, hardware and products and maps the dependencies between systems, including each system's internal components and dependencies. Its considerations add six practical points, paraphrased here:

• Network evidence is a hint, not a design: data exchanges found during network mapping usually indicate dependencies, but they may not be part of the intended design.
• People confirm intent: architectural design artefacts and subject matter experts may be needed to decide whether a dependency is intended or essential.
• Pre-built systems have insides: mapping should capture the internal dependencies of standard and pre-built systems, such as an appliance or a packaged application, in the complete model.
• Prioritise critical systems: dependencies of critical systems should be prioritised for supply chain risk analysis.
• Structure matters: the model should identify the integral components of a named system and how they are structured to form it.
• Use external knowledge bases: a product's configuration may fix its dependencies, and external knowledge such as package manager data is described as essential.

The boundary with the siblings is worth keeping clear. Service Dependency Mapping records which services a service calls at runtime; Data Exchange Mapping records which data flows between systems; System Dependency Mapping records what a system is built from and what it needs to function. The same database server can appear in all three, for different reasons. See the D3-SVCDM Service Dependency Mapping and the D3-DEM Data Exchange Mapping.

What to record and where the data comes from

The table below is NHI Mgmt Group guidance on layers and sources, not part of D3FEND.

The IBM TADDM documentation cited by D3FEND shows what discovery tooling records: transactional dependencies between application components, service dependencies on infrastructure such as DNS, LDAP and NFS, system dependencies of an application server on its host, IP-level connections where the application cannot be identified, and application-to-application dependencies. Automated discovery products of this kind, configuration management databases, cloud provider inventories and SBOM platforms are all valid tooling; none is required. The OMG Unified Architecture Framework (version 1.3, April 2026, per the OMG specification page) is the modelled-architecture reference D3FEND cites, for organisations that already maintain formal architecture views.

How to build it

1. Pick the named systems. Start from the asset inventory and the list of critical business services, and choose 10 to 20 systems that support critical activities. Give each a single owner. See the Asset Inventory and CMDB Security Guide.
2. Decide the store. Use the CMDB or a graph store that already holds asset records, so each edge points to a recorded asset. Agree a small edge vocabulary (built from, runs on, hosted by, requires service, depends on product, authenticates as).
3. Load discovered data first. Import SBOMs from the build pipeline, image manifests and host software inventories. This gives versions and is cheap to refresh. See the SBOM Guide.
4. Add the designed view. Run a short workshop per system with its architect and operators to add dependencies discovery cannot see (SaaS products, batch file drops, manual processes) and to mark each discovered edge as intended, essential or unexpected, as D3FEND's considerations recommend.
5. Capture identities on edges. For each system-to-system edge, record the credential type and the account or workload identity used.
6. Automate refresh. Regenerate SBOM and platform layers on every build and deployment; schedule the designed layer for review at each major change and at least annually (an example interval, not a standard).
7. Test the model. Run a tabletop query: "a critical vulnerability is announced in component X; which named systems and owners are affected?" Time the answer and compare it with what operators know.

Roll back is simple because the technique observes rather than changes systems; the risk is in discovery agents or credentials used to collect data, which should be read-only and themselves inventoried.

How it feeds other D3FEND techniques

• System Vulnerability Assessment (D3-SYSVA): relates component vulnerabilities to the configuration and internal dependencies of the system; without a dependency model it is only a list of findings. See the D3-SYSVA System Vulnerability Assessment.
• Software Inventory (D3-SWI) and Asset Vulnerability Enumeration (D3-AVE): inventory gives the nodes; the dependency model gives the structure that turns an enumerated vulnerability into affected systems. See the D3-SWI Software Inventory.
• Operational Dependency Mapping (D3-ODM): links business activities to the systems that support them, which is how D3-SYSDM knows which systems are critical. See the D3-ODM Operational Dependency Mapping.
• Software Update (D3-SU): the model shows which systems a patch or upgrade touches and in what order to test them. See the D3-SU Software Update.

For the parent technique and how the four children are sequenced, see the MITRE D3FEND System Mapping implementation guide.

Where identity fits

A system that depends on another usually proves who it is: a database login in a connection string, a cloud workload identity, a certificate for mutual TLS or an API key for a SaaS product. If the dependency model records that identity, two practical questions become answerable: which systems break if this credential is rotated or revoked, and which systems an attacker can reach after stealing it. Ownerless service accounts often surface during this exercise because nobody can say which dependency they serve. See How to assign owners to orphaned service accounts.

Detection and measurement

System Dependency Mapping produces few alerts of its own. Useful signals are a new runtime dependency that is not in the model, a component appearing in an SBOM that was not there in the previous build, and a critical system whose dependency data has gone stale. Metrics we suggest (targets are examples, not standards):

Limits and common failure patterns

• Stopping at the network map. Flow data shows connections, not what a system is built from; a library or a base image never appears in flow logs.
• Treating discovered edges as design. D3FEND warns that observed exchanges may not be intended. Unreviewed edges hide unauthorised dependencies in plain sight.
• Ignoring the insides of products. Appliances and packaged applications contain their own libraries; supplier SBOMs or vendor advisories are needed to model them.
• One-off diagrams. A dependency diagram drawn for an audit and never refreshed is wrong within months. Tie refresh to builds and deployments.
• Mapping everything at once. Starting with every system produces a large, shallow and quickly stale model. Start with critical systems, as D3FEND recommends.
• Unowned collection credentials. Discovery tools often run with broad read access across estates; their accounts belong in the privileged and non-human identity inventory.

Supply chain incidents show why the model matters: when a component deep in the stack is compromised, response speed depends on knowing where it runs. See the MITRE ATT&CK T1195 Supply Chain Compromise.

Framework mapping

D3FEND does not map D3-SYSDM to other frameworks. The table is NHI Mgmt Group's reading of where the practice supports existing controls.

Practitioner checklist

• Choose the critical named systems and give each an owner.
• Agree an edge vocabulary and store edges against recorded assets.
• Generate SBOMs on every build and load them automatically.
• Add platform, hosting and infrastructure service layers from discovery and cloud inventories.
• Review each critical system with its architect and mark edges intended, essential or unexpected.
• Record the credential and owner on every system-to-system edge.
• Run a quarterly tabletop query for a hypothetical component vulnerability and time the answer.
• Inventory the accounts used by discovery tooling and keep them read-only.

Standards and references

• MITRE D3FEND: System Dependency Mapping (D3-SYSDM)
• MITRE D3FEND: System Mapping (D3-SYSM)
• OMG: Unified Architecture Framework (UAF)
• IBM: Tivoli Application Dependency Discovery Manager 7.3.0, Dependencies between resources
• CISA: Software Bill of Materials (SBOM)
• NIST: SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: MITRE D3FEND System Mapping implementation guide · D3-SVCDM Service Dependency Mapping · SBOM Guide · Asset Inventory and CMDB Security Guide · MITRE D3FEND Guide