The point at which software consumers can no longer reliably distinguish legitimate packages from malicious ones using normal trust signals. In practice, it happens when package publication, maintainer identity, and install-time execution are all assumed safe without independent verification.
Expanded Definition
Dependency Trust Collapse describes the failure mode that appears when package ecosystems become too trusting to distinguish legitimate software from malicious software using normal signals such as maintainer reputation, version history, or routine install-time behavior. In NHI and software supply chain security, the concern is not only whether a package is signed or popular, but whether consumers independently verify provenance, publisher identity, and execution intent before the code is allowed to run.
The term sits at the intersection of dependency management, software provenance, and runtime trust. It matters because modern build systems often auto-fetch packages, resolve transitive dependencies, and execute install scripts with broad access. That makes the trust decision happen before meaningful inspection, which is why guidance is still evolving across vendors and ecosystems. The closest operational principle is Zero Trust, as reflected in the NIST Cybersecurity Framework 2.0: assume nothing is trusted by default and verify continuously.
The most common misapplication is treating package popularity or namespace familiarity as proof of safety, which occurs when teams approve dependencies based on reputation instead of independent provenance checks.
Examples and Use Cases
Implementing dependency trust controls rigorously often introduces release friction, requiring organisations to weigh developer velocity against stronger verification and tighter install-time restrictions.
- A CI pipeline installs a newly published package that uses a convincing maintainer name and then runs a post-install script, so provenance checks and allowlists are needed before execution.
- A security team reviews the LiteLLM PyPI package breach as a reminder that package trust cannot rely on repository presence alone.
- An internal platform team requires signed artifacts and verified source links before a dependency can enter a build, aligning package intake with the trust principles described in NIST Cybersecurity Framework 2.0.
- A dependency bot proposes a transitive upgrade that pulls in a lesser-known library, and the team blocks it until the maintainer, checksum, and release lineage are independently checked.
- An AI agent is allowed to install tools at runtime, but only from a controlled registry with verified metadata, because autonomous execution amplifies the blast radius of untrusted dependencies.
Why It Matters in NHI Security
Dependency Trust Collapse is an NHI problem because software dependencies now behave like non-human identities: they publish artifacts, inherit permissions, execute code, and interact with secrets. When those identities are assumed safe without verification, attackers can exploit package typosquatting, maintainer compromise, or malicious updates to reach tokens, API keys, and CI/CD controls. That is why NHIMG reports that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, and why dependency compromise is often a pathway to broader identity abuse.
The operational lesson is that trust collapse is usually visible only after a breach, when investigators discover that a dependency had the power to read secrets, sign builds, or alter deployment behavior. At that point, the issue is no longer just package hygiene; it becomes a governance problem for NHI lifecycle control, privilege containment, and supply chain verification, alongside guidance from NIST Cybersecurity Framework 2.0 and the NHI risk patterns documented in the LiteLLM PyPI package breach. Organisations typically encounter the full impact only after a dependency has already executed and touched credentials, at which point Dependency Trust Collapse 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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, 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 | Addresses unsafe secret exposure and trust assumptions around machine identities. |
| NIST CSF 2.0 | PR.DS-6 | Protects data in transit and at rest, including software supply chain artifacts. |
| NIST Zero Trust (SP 800-207) | SC-12 | Zero trust requires explicit verification rather than implicit ecosystem trust. |
| NIST AI RMF | AI systems depend on external components whose trustworthiness must be governed. | |
| OWASP Agentic AI Top 10 | A2 | Agentic systems can autonomously fetch and execute dependencies, increasing exposure. |
Treat every dependency as untrusted until authenticated, authorized, and continuously validated.
Related resources from NHI Mgmt Group
- What is the difference between automating dependency updates and granting them blind trust?
- What should security teams do when a verifier becomes a core trust dependency?
- What do teams get wrong about dependency provenance and package trust?
- How do organisations decide when to trust an audited open-source dependency?
