A ghost dependency is a hidden upstream or downstream service relationship that teams believe has been removed but still exists in code or runtime flow. In API-heavy environments, ghost dependencies are dangerous because they hide compliance, resilience, and access risk.
What a ghost dependency is
A ghost dependency is not simply an extra integration, it is a relationship that teams think is gone but still survives in code paths, runtime calls, configuration, or transitive dependencies. The operational danger is that the system still relies on it even after ownership, documentation, or reviews say otherwise.
That gap between perceived and actual dependency state is what makes the term useful in security work. It explains why deletion, decommissioning, or migration projects can leave behind hidden coupling that only shows up when traffic, auth, or failure handling reaches the old path.
Where ghost dependencies show up
Ghost dependencies often appear in API-heavy systems, dependency graphs, service meshes, shared libraries, event consumers, or build pipelines. A team may remove a direct integration while a wrapper, fallback route, cached credential, or transitive package still calls the old service.
They can be especially hard to spot when the dependency is indirect. For example, code may stop naming a service explicitly, yet a library, SDK, webhook handler, or retry flow still reaches it at runtime. That is why inventory alone is not enough if runtime behavior is not also checked.
In supply chain terms, a package or module can remain present even after the team believes it has been replaced, which means the old trust relationship is still active. NHIMG’s LiteLLM PyPI package breach is a useful reminder that dependency trust can persist in ways teams do not expect.
Why ghost dependencies matter for security and resilience
Ghost dependencies create blind spots in access, resilience, and change management. If a system still depends on a removed service, then outage impact, data flow, authorization scope, and compliance exposure may all be larger than the current architecture diagram suggests.
They also complicate incident response. A dependency that is believed dead may still be a viable attack path, a hidden data route, or a recovery blocker if the old endpoint, credential, or integration is still reachable.
For API-driven environments, the problem is not just broken functionality. It is that hidden reachability can preserve trust assumptions, secret use, and upstream or downstream coupling long after a migration is supposed to have eliminated them. OWASP API Security Top 10 remains relevant because authorization and inventory failures are common ways stale relationships stay exploitable.
How to think about ghost dependency detection
Detection usually requires more than static documentation review. Teams need to compare declared dependencies with runtime telemetry, service maps, logs, traces, network flow data, and deployment artifacts to confirm whether a relationship is truly gone.
That same cross-check applies to deprecation and migration work. A dependency should only be treated as removed when code, configuration, permissions, traffic, and fallback behavior all agree. If one layer still references it, the dependency is not a ghost, it is still active.
Open source dependency hygiene also matters because stale or transitive packages can preserve hidden trust and update paths. OpenSSF provides broadly useful supply chain guidance for understanding and reducing that kind of hidden exposure.
Risk and Threat Considerations
Ghost dependencies matter because they create false confidence. Teams may believe an external service, internal microservice, or package has been removed, while code still reaches it and preserves a path for data access, outage propagation, or unauthorized use.
Failure mechanism: stale references survive in code, runtime flow, retries, or transitive dependencies, so the hidden relationship continues to execute even after the team believes it has been eliminated.
Impact: the organisation can retain unseen access paths, unexpected downtime dependencies, and compliance gaps, and attackers may exploit the forgotten relationship as a quieter route into data, secrets, or service trust.
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 addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-16 — Application Software Security | Ghost dependencies are often exposed through unsupported or stale software relationships. |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Hidden runtime links often persist because configuration and deployment state diverge from design. | |
| Recommendation — Inventory and verify third-party and internal dependencies before release and retirement. Baseline configurations so removed services and routes cannot remain reachable. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | Ghost dependencies reveal gaps between documented components and what actually exists in runtime flow. |
| SC-7 — Boundary Protection | Persistent hidden service paths can bypass intended trust boundaries and segmentation assumptions. | |
| Recommendation — Maintain an accurate component inventory that includes dependencies and runtime-relevant components. Enforce boundaries so stale service paths cannot continue crossing trust zones. | ||
| OWASP API Security Top 10 | API9 — Improper Inventory Management | Ghost dependencies are a form of missed inventory where APIs or service relationships remain active unexpectedly. |
| Recommendation — Track every API and service relationship so deprecated paths are discovered and removed. | ||
| SLSA | Supply-chain Levels for Software Artifacts | Transitive and hidden dependency relationships are central to build and artifact integrity. |
| Recommendation — Use provenance and dependency controls to detect and reduce hidden supply-chain coupling. | ||
Practitioner Guidance
Why practitioners should care: ghost dependencies are a release and governance problem, not just a cleanup issue. If removal is judged only by source code search or ticket closure, teams can miss the runtime paths that still matter operationally.
What to watch for: after a migration or decommissioning effort, verify that traffic, error handling, identity assumptions, and configuration all stopped depending on the old service. If any production call path still exists, the dependency is still real.
Practitioner takeaway: treat “removed” as a state to prove, not a state to assume.
Related resources from NHI Mgmt Group
- When does a dependency compromise become an identity incident?
- What is the difference between shadow agents and ghost identities?
- How should teams slow down malicious dependency updates without breaking delivery?
- What is the difference between automating dependency updates and granting them blind trust?