A stack dependency is a relationship where one infrastructure stack must complete before another can run correctly. It lets teams pass runtime outputs from an upstream stack into a downstream stack, so sequencing, inputs, and triggers follow the actual build order rather than manual intervention.
Expanded Definition
A stack dependency is the declared or implied ordering relationship between infrastructure stacks, where one stack must finish provisioning, exporting outputs, or reaching a stable state before another can safely consume those outputs. In practice, the term is used most often in Infrastructure as Code, platform engineering, and CI/CD orchestration, where sequencing is part of the deployment model rather than a manual handoff. It is closely related to dependency graph, but a stack dependency is specifically about cross-stack runtime coupling, not just package-level versioning or library imports.
In NHI security, stack dependencies matter because the upstream stack may create secrets, roles, certificates, service accounts, or trust relationships that downstream workloads rely on. That makes lifecycle timing, access scope, and output handling part of the security boundary. Guidance varies across vendors on how much dependency metadata should be explicit versus inferred, so teams should treat the dependency as a governed control point rather than a convenience feature. For control discipline, map the deployment relationship to least-privilege expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls. The most common misapplication is treating stack outputs as harmless build metadata, which occurs when credentials or trust anchors are passed through unreviewed pipeline variables.
Examples and Use Cases
Implementing stack dependencies rigorously often introduces deployment coupling and failure sensitivity, requiring organisations to weigh deterministic automation against slower rollback and change coordination.
- An identity stack provisions a service account and exports its client ID to an application stack, so the app can authenticate without waiting for manual credential entry.
- A secrets stack creates a vault path and access policy first, then a workload stack consumes the secret reference after the dependency resolves, reducing fragile hardcoding.
- A network foundation stack defines private endpoints before an observability stack starts, ensuring telemetry agents can reach internal services only after the approved route exists.
- A platform team uses explicit dependencies to stop a downstream Kubernetes add-on from starting until the upstream cluster role bindings are active.
- Incident analysis of the LiteLLM PyPI package breach shows why dependency chains must be visible when software delivery paths can expose secrets; for adjacent identity guidance, see NIST SP 800-63 Digital Identity Guidelines for assurance concepts that often shape downstream trust decisions.
These use cases are common in multi-stack environments where outputs from one control plane become inputs to another, especially when secrets, tokens, or role bindings are generated on demand.
Why It Matters in NHI Security
Stack dependencies become security-relevant because NHI failures rarely happen in isolation. An upstream stack that leaks an API key, exports an over-privileged role, or leaves a certificate in an accessible output can propagate compromise into every dependent workload. That is why dependency hygiene is part of secret governance, access scoping, and blast-radius reduction, not just deployment convenience. NHIMG research shows that 97% of NHIs carry excessive privileges, which broadens the attack surface when one stack hands off trust to another. Poorly managed dependencies can also hide where a secret originated, making rotation and offboarding difficult after a breach.
This is where visibility matters: stack dependency chains should be audited alongside secret placement, rotation state, and service-account ownership. The same operational pattern appears in compromises where automation was trusted more than its own outputs. The 80% of identity breaches involving compromised non-human identities underscores how often downstream systems inherit risk from an upstream identity decision. When dependency links are documented and enforced, recovery is faster; when they are implicit, the organisation may not know which stacks must be rebuilt or re-keyed. Organisaties typically encounter cascading access failures only after an upstream stack is changed or breached, at which point stack dependency becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Stack dependencies often move secrets and trust outputs between NHI workloads. |
| NIST CSF 2.0 | PR.AC-4 | Access rights must follow the dependency chain and remain least privilege. |
| NIST SP 800-63 | AAL2 | Downstream stacks often inherit assurance requirements from upstream identity issuance. |
| NIST Zero Trust (SP 800-207) | SC.SR-1 | Explicit dependency boundaries support zero-trust segmentation of trust relationships. |
| NIST AI RMF | Dependency chains change operational risk when automation or AI systems deploy stacks. |
Document stack inputs, outputs, and failure modes so automated deployment decisions remain accountable.
Related resources from NHI Mgmt Group
- When does a dependency compromise become an identity incident?
- How should security teams implement continuous identity without replacing their IAM stack?
- How should teams slow down malicious dependency updates without breaking delivery?
- What is the difference between automating dependency updates and granting them blind trust?
