Dependency Drift

Expanded Definition

Dependency drift describes the security and governance gap created when the surrounding dependency chain changes faster than assessment, approval, and inventory processes can keep up. In practice, the “dependency” may be a subcontractor, a SaaS integration, an API path, a package, a hosting layer, or a delegated identity used by automation. The risk is not the change itself, but the loss of control over who can access what, through which pathway, and under which trust assumptions. In cybersecurity terms, it is a variant of exposure drift: the asset graph, trust boundaries, and access relationships shift continuously while security evidence is usually collected on a schedule. NIST’s NIST Cybersecurity Framework 2.0 is relevant because it emphasises ongoing governance, inventory, and risk management rather than one-time review. The most common misapplication is treating dependency drift as a procurement issue only, which occurs when teams review vendors but ignore runtime access paths, embedded secrets, and downstream service accounts.

Examples and Use Cases

Implementing dependency control rigorously often introduces review overhead and integration friction, requiring organisations to weigh faster delivery against tighter change visibility.

• A cloud application adds a new payment subprocesser, but the security questionnaire still reflects the old hosting and access model.
• A CI/CD pipeline gains a new package source, and a maintained dependency quietly inherits elevated build permissions before the next audit cycle.
• A third-party analytics tool rotates infrastructure, changing data flow and token handling without a corresponding update to the trust register.
• An OAuth integration remains approved, but its issuing app changes ownership or configuration, creating drift in delegated access. NHIMG’s Salesloft OAuth token breach shows how access assumptions can outlive the environment that created them.
• A software package is updated upstream, and a malicious or compromised release path affects downstream users, as illustrated by the LiteLLM PyPI package breach.

For NHI-heavy environments, dependency drift often includes service accounts, tokens, and API keys that outlive the systems they were issued for, which makes identity lifecycle controls as important as vendor review.

Why It Matters for Security Teams

Dependency drift matters because it hides change in places that traditional review cycles rarely inspect. When teams believe a dependency map is current, they may miss new subcontractors, altered ownership, stale secrets, or newly exposed tool connections. That gap is especially dangerous for NHI governance, where machine identities and tokens often persist across product, infrastructure, and partner changes. NHI Mgmt Group research shows that only 5.7% of organisations have full visibility into their service accounts, which helps explain why drift so often becomes a control failure rather than a documentation issue. The Ultimate Guide to NHIs also reports that 92% of organisations expose NHIs to third parties, making dependency drift a supply chain and delegated-access concern at the same time. Security teams need this term because it connects change management, identity governance, and trust boundary validation into one operational problem. Organisations typically encounter the consequences only after a compromised integration, stale token, or unexpected supplier change, at which point dependency drift becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should security teams think about a compromised integration like Drift?
• How can security teams reduce privilege drift in Kubernetes RBAC?
• When does a dependency compromise become an identity incident?
• Runtime Drift