A delivery dependency is any internal or external service a build pipeline needs to compile, test, cache, package, or release software. These dependencies matter because they can fail silently, create hidden trust chains, or become an outage point that affects deployment reliability and release integrity.
Expanded Definition
In NHI security, a delivery dependency is more than a build input. It is any package, service, cache, signing component, artifact repository, or automation endpoint that a pipeline relies on to compile, test, package, or release software. The term is closely related to software supply chain trust, but it is narrower in one important way: it focuses on the operational dependencies that can stop delivery, alter artifacts, or silently change what gets shipped.
Definitions vary across vendors and platform teams, especially when pipelines span internal registries, external package ecosystems, and AI-assisted build tools. For that reason, the safest interpretation is functional: if the pipeline cannot complete without it, the dependency is in scope. This includes secrets used by build jobs, identity tokens for artifact access, and remote services that inject code, metadata, or signatures. NIST Cybersecurity Framework 2.0 is useful here because it frames the broader governance problem around resilient, controlled delivery and third-party risk.
The most common misapplication is treating delivery dependencies as ordinary developer tools, which occurs when teams ignore the identity, integrity, and availability risks attached to the pipeline itself.
Examples and Use Cases
Implementing delivery dependency controls rigorously often introduces latency and maintenance overhead, requiring organisations to weigh release speed against supply chain assurance.
- A private package registry fails during release, and the pipeline cannot fetch a base library, causing a blocked deployment even though the application code is unchanged.
- A CI job uses a short-lived token to pull artifacts from a remote repository, and the token becomes a hidden trust anchor if it is not rotated or scoped tightly.
- A cached dependency is poisoned upstream, so subsequent builds reproduce the compromised artifact until checksum validation or pinning detects the drift. The LiteLLM PyPI package breach shows how dependency trust can fail in the package ecosystem before teams notice the impact.
- A signing service required for release approval is unavailable, so the pipeline cannot produce a trusted artifact, turning a security control into a single point of failure.
- An external test harness changes behavior without notice, and the pipeline passes or fails for reasons unrelated to the actual build, masking release integrity problems.
These patterns map to the supply chain concerns discussed by NHI Management Group in its Ultimate Guide to NHIs, especially where service identities and secrets are embedded into delivery paths. For implementation guidance on trusted automation and identity-aware controls, the NIST Cybersecurity Framework 2.0 is a useful baseline.
Why It Matters in NHI Security
Delivery dependencies matter because they often depend on NHIs: service accounts, API keys, bot tokens, signing credentials, and machine-issued certificates. When those identities are overprivileged, poorly rotated, or stored outside a secrets manager, the pipeline inherits the same exposure. NHI Mgmt Group reports that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes delivery infrastructure a frequent concentration point for compromise.
A weak understanding of delivery dependencies can also distort incident response. Teams may search the application tier while the real outage is a broken package feed, revoked signing certificate, or inaccessible artifact service. That delay can enlarge blast radius, especially when one dependency supports many repositories or many release lanes. The operational lesson is that dependency hygiene is not only a build concern; it is an identity governance concern.
Organisations typically encounter release failure, poisoned artifacts, or credential exposure only after a pipeline stalls or a trusted package is compromised, at which point delivery dependency management 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 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC | Covers supply chain governance and third-party dependency risk in delivery paths. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Secret handling in CI/CD and build automation is central to delivery dependency risk. |
| NIST AI RMF | Supports risk mapping for automated systems that rely on external services and artifacts. |
Assess delivery dependency failures as operational and trust risks, then document mitigations.
