Dependency Resolution

What dependency resolution does

Dependency resolution turns a package manifest into a concrete set of installable artifacts. It is the decision layer that determines which transitive libraries, helpers, and version ranges the build actually consumes, so its output shapes both functionality and the software supply chain that will run in production.

Because that decision happens before runtime, it is easy to overlook. Yet a small change in resolution behavior can alter the full dependency tree, including code that the development team never named directly.

Why dependency resolution is security-sensitive

Dependency resolution becomes security-sensitive when the build trusts a registry, a version selector, or a transitive package that the maintainer did not inspect closely. A poisoned dependency can introduce malicious logic, pull in an unexpected package, or swap a safe implementation for a compromised one without causing obvious build errors.

That makes the process a supply-chain control point, not just a developer convenience. The security question is not only whether the requested package exists, but whether the resolved graph is the one the team intended and can later explain.

Open source ecosystems are especially exposed when a package name is similar to an internal dependency, when a registry route changes, or when resolution rules permit broad version drift. Guidance from OpenSSF is useful here because it focuses on open source supply-chain hardening and dependency integrity practices.

How dependency resolution fails

The common failure modes are subtle: typo-squatting, dependency confusion, overly permissive version ranges, and transitive package substitution. Each can cause the build to resolve to code that looks legitimate at install time but was not the code the project meant to consume.

Resolution can also fail through environment drift. Two builds that start from the same manifest may produce different dependency trees if the registry state, lockfile discipline, or resolver behavior is inconsistent. That creates reproducibility problems and makes incident investigation harder later.

Once a malicious package is resolved and installed, the compromise can spread beyond the immediate package boundary. A single bad transitive dependency can affect authentication flows, data handling, update logic, or any other code path that imports it.

What good dependency control looks like

Strong dependency resolution practices aim to make package selection deterministic, reviewable, and repeatable. In practice that means treating lockfiles, pinned versions, trusted registries, and dependency review as part of the security baseline, not as optional build hygiene.

Teams should also expect to verify what was actually resolved, not only what was declared. SBOM generation, build attestation, and repository policy checks help bridge the gap between intended dependencies and installed dependencies.

When the subject is software delivery integrity, the strongest control is to prevent surprise at resolution time, then preserve evidence of the resolved graph for later review. SLSA is directly relevant because it frames build provenance and artifact integrity as supply-chain security requirements.

For governance over the wider development pipeline, OWASP SAMM provides a maturity lens for embedding secure dependency handling into software assurance practices.

How organisations reduce dependency risk

Organisations reduce dependency risk by combining prevention, visibility, and controlled updating. That includes inventorying dependencies, limiting which registries a build may trust, reviewing new transitive additions, and monitoring for unexpected graph changes after merge or release.

Build security frameworks matter because resolution is where supply-chain trust becomes concrete. When the resolved package set is deterministic, the team can compare intended versus actual inputs, investigate anomalies faster, and block suspicious additions before they reach users.

In practice, dependency resolution should be treated as a control point that deserves the same discipline as code review or release approval. For broader control mapping, the security controls catalog in NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference for configuration management, system integrity, and software oversight.

Related resources from NHI Mgmt Group

• 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?
• What breaks when DNS becomes a dependency for rapid internal changes instead of stable name resolution?