Package manager behaviour that fetches or activates indirect dependencies without drawing obvious attention from the developer. Attackers exploit this path to place malicious code deeper in the dependency tree, where it is less likely to be reviewed before execution.
What Hidden Dependency Resolution Does
Hidden dependency resolution is the package-manager behaviour that discovers, fetches, or activates indirect dependencies for you. That convenience reduces setup friction, but it also means code can enter the build or runtime path without the developer explicitly reviewing every package.
The key security consequence is that trust shifts from the top-level manifest alone to the entire dependency tree. In practice, a dependency may be installed because another package requested it, because a resolver chose the latest compatible version, or because transitive metadata pulled it in automatically.
Why It Matters in Software Supply Chains
Hidden resolution broadens the attack surface of package ecosystems. A malicious package author, compromised maintainer account, or typosquatted library can be introduced several layers deep, where it is less likely to receive the same scrutiny as a direct dependency.
That is why open source supply-chain programmes focus on dependency visibility, package hygiene, and provenance controls. OpenSSF provides supply-chain guidance and projects aimed at reducing the risk of unreviewed or untrusted components entering software delivery.
When hidden dependencies are resolved automatically, the practical question is not only “what did I ask for?” but also “what else did the resolver bring in, and why?” That distinction matters when the package tree is large, shared across teams, or refreshed frequently.
How Attackers Abuse the Dependency Tree
Attackers often target the weakest point in the tree, not the most visible one. By placing malicious behaviour in an indirect dependency, they can wait for normal installs, updates, or post-install hooks to execute code that developers never intended to run.
In source ecosystems, this can enable credential theft, build tampering, or persistence inside CI and developer environments. An example is the LiteLLM PyPI package breach, which illustrates how supply-chain compromise can expose users through a package path that appears routine on the surface.
The deeper the dependency sits, the more likely it is to inherit trust from the parent package and the less likely it is to be manually inspected. That makes hidden resolution especially attractive when the attacker wants code execution that looks like ordinary package behaviour.
Where Defensive Control Breaks Down
Defence fails when teams assume their dependency list is complete just because the direct manifest is complete. Hidden resolution creates blind spots in inventory, review, and change control, especially when package managers resolve versions dynamically or when transitive dependencies change without deliberate approval.
Controls need to account for the full resolved graph, not just the declared one. Requirements such as provenance checking, dependency pinning, allowlisting, and reproducible builds become more important when the resolver can silently widen the software supply chain.
Frameworks for software provenance and secure build integrity are relevant here. SLSA helps teams harden artifact provenance, while OWASP SAMM supports more disciplined security practices across the development lifecycle.
Risk and Threat Considerations
Hidden dependency resolution creates a material software supply-chain risk because unreviewed code can be introduced through trusted package mechanisms. The main danger is not just accidental inclusion, but attacker-controlled code execution through transitive packages that inherit the parent package’s legitimacy.
Failure mechanism: A resolver, installer, or build tool activates indirect dependencies automatically, allowing malicious code, poisoned updates, or compromised packages to enter the execution path without direct developer intent.
Impact: This can lead to source tampering, credential exposure, build compromise, malware propagation, or a broader compromise of developer and CI environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, OWASP SAMM, NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain security levels | Hidden dependency resolution affects artifact provenance and integrity. |
| Recommendation — Require verifiable build provenance for all resolved packages. | ||
| OWASP SAMM | Software assurance maturity model | Dependency control is part of secure software delivery maturity. |
| Recommendation — Bake dependency review and secure release practices into the SDLC. | ||
| NIST CSF 2.0 | PR.DS-10 — Integrity mechanisms | Automatic dependency activation can undermine software integrity guarantees. |
| ID.RA-05 — Threats, vulnerabilities and likelihoods are used to inform risk assessments | Transitive package compromise is a supply-chain threat that should be risk assessed. | |
| Recommendation — Use integrity checks to detect unexpected package changes. Include transitive dependency compromise in risk assessments. | ||
| NIST SP 800-53 Rev 5 | SA-12 — Supply Chain Protection | Indirect packages are a supply-chain exposure that needs controls over acquisition and provenance. |
| Recommendation — Apply supply-chain protections to third-party package acquisition. | ||
| CIS Controls v8 | CIS-15 — Service Provider Management | Indirect dependencies are third-party software whose trust and provenance must be governed. |
| Recommendation — Track and govern third-party software dependencies and providers. | ||
Practitioner Guidance
Why practitioners should care: Treat the resolved dependency graph as the real security boundary, not only the declared manifest. Review and monitor transitive packages with the same seriousness as top-level dependencies when they can affect build or runtime behaviour.
Practitioner takeaway: If your tooling cannot show exactly what was resolved, you do not fully know what you are shipping.
Related resources from NHI Mgmt Group
- When does browser standardisation reduce risk versus create hidden dependency risk?
- What breaks when dependency resolution is treated as a routine build setting?
- What breaks when dependency resolution depends only on lockfiles?
- What is the difference between manifest-based dependency discovery and full dependency-tree resolution?