The set of contracts, venues, and external protocols that can influence how a vault holds, prices, or moves assets. In DeFi, the real security boundary extends across that graph because each dependency can change the vault’s risk even when the vault code itself is unchanged.
What a vault dependency graph actually captures
A vault dependency graph describes the external relationships that shape a vault’s real security boundary: contracts, venues, price oracles, bridges, staking routes, and other protocols the vault depends on to value, hold, or move assets. The point is not the vault code alone, but the chain of assumptions that code inherits from elsewhere.
This matters because a vault can appear unchanged while its exposure changes underneath it. A dependency can alter pricing, introduce liquidity constraints, change redemption behaviour, or create a new failure path even when the vault’s own logic is stable.
Why the graph, not just the vault, defines exposure
In DeFi, security is often distributed across composable systems. A vault may rely on one protocol for pricing, another for custody-like execution, and another for settlement or routing. If any of those components changes trust assumptions, the vault’s effective risk changes with it.
That makes the dependency graph a security model, not a design diagram. It helps explain why two vaults with similar code can have very different risk profiles depending on the venues, contracts, and integration paths they use.
It also makes hidden coupling visible. If a vault depends on a small set of external protocols, a failure, exploit, pause, or governance change in one dependency can quickly become a vault-level issue.
Common dependency patterns that matter
Most vault dependency graphs include a mix of technical and economic dependencies. Technical dependencies include smart contracts, bridges, routers, oracles, and vault adapters. Economic dependencies include the venues that determine asset value, liquidity depth, slippage, and the ability to exit positions on demand.
Some dependencies are direct, while others are second-order. For example, a vault may not call a protocol directly but still inherit risk from a market used for pricing or from a downstream venue used for unwinding positions. Those paths are still part of the graph because they can influence loss, delay, or mispricing.
Dependency graphs are also useful for spotting concentration. A vault that appears diversified may still rely on the same oracle source, governance structure, or liquidity venue across multiple assets, which means one failure mode can affect many positions at once.
How practitioners use the graph in review and monitoring
A dependency graph is most useful when it is kept current and tied to real operational checks. Teams should know which external contracts, venues, and protocols are in scope, which ones affect pricing versus execution, and which ones can change the vault’s behaviour without a code change.
It should also feed monitoring and incident response. When an upstream protocol is paused, exploited, reconfigured, or delisted, the vault team needs to understand whether the impact is informational, economic, or immediately actionable. That is the difference between a dependency map and a live control surface.
For a broader supply-chain view of how dependency relationships affect security posture, SBOM Guide is useful because it treats dependency visibility as an operational security problem, not just an inventory exercise.
When the graph includes assets, roles, secrets, or vault access paths, Guide to the Secret Sprawl Challenge helps connect dependency awareness to the broader problem of secret exposure and credential sprawl.
What changes when a dependency is compromised or replaced
The main practical lesson is that vault risk is dynamic. A dependency can be upgraded, paused, censored, repriced, or attacked, and each of those changes can alter the vault’s behaviour even if the vault itself is untouched. In DeFi, that means security review has to extend beyond the vault contract to every material external assumption it relies on.
For lifecycle and rotation issues around changing dependencies, Guide to NHI Rotation Challenges is relevant because it frames dependency-aware rotation and replacement as part of control continuity.
In practice, a dependency graph is most valuable when it is treated as a living artifact, updated whenever the vault’s external relationships, pricing sources, or execution routes change.
Risk and Threat Considerations
Vault dependency graphs create exposure because the vault’s safety can be undermined by failures outside its own codebase. If an external protocol is exploited, paused, censored, or economically manipulated, the vault may misprice assets, lose the ability to rebalance, or inherit losses through an otherwise valid integration.
Failure mechanism: An attacker or failure in one upstream venue, oracle, bridge, or adapter changes the vault’s operating assumptions, then propagates incorrect pricing, blocked execution, or misrouted assets into the vault.
Impact: The vault may suffer direct financial loss, bad debt, withdrawal delays, broken accounting, or forced deleveraging, even when the vault contract itself has no defect.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while SLSA, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API9 — Improper Inventory Management | Dependency graphs rely on complete inventory of exposed integrations and external paths. |
| Recommendation — Inventory all external APIs and dependency paths that can influence vault pricing or asset movement. | ||
| SLSA | Supply Chain Integrity | The term centers on trust in upstream components and dependency relationships that affect runtime behaviour. |
| Recommendation — Track and attest upstream dependency changes that can alter vault behaviour or integrity. | ||
| NIST CSF 2.0 | ID.AM-01 — Identities and assets are inventoried | A vault dependency graph is fundamentally an inventory of material assets, venues, and relationships. |
| Recommendation — Maintain an up-to-date inventory of every external dependency that can affect vault risk. | ||
| CIS Controls v8 | CIS-15 — Service Provider Management | The graph includes third-party venues and protocols whose changes can affect the vault's risk posture. |
| Recommendation — Assess and monitor third-party dependencies that can change vault exposure or availability. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | When vault dependencies include delegated or service-style access, third-party risk becomes material. |
| Recommendation — Review third-party dependency trust and isolate any external access that can affect vault assets. | ||
Practitioner Guidance
Why practitioners should care: The dependency graph is the difference between “the vault code is unchanged” and “the vault’s real risk has changed.” Teams should treat external contracts and venues as part of the vault’s security boundary, because that is where many loss scenarios begin.
What to watch for: Review should focus on protocol upgrades, oracle changes, liquidity shifts, governance actions, and any new routing path that expands the graph. If a dependency can alter pricing or asset movement, it deserves the same operational attention as a vault-side code change.
Practitioner takeaway: A vault is only as stable as the dependencies that can change its valuation, settlement, and redemption behaviour.
Related resources from NHI Mgmt Group
- What breaks when teams cannot see the full dependency graph in an application security program?
- What is the difference between lockfile based dependency scanning and graph based dependency visibility?
- What is the difference between a service dependency graph and a relationship graph?
- How does Dependency Graph SBOM work?