Dependency resolution is the process of selecting the exact packages and versions a build will install. In modern pipelines, it is a critical security step because a typo, registry mismatch, or poisoned transitive dependency can change what gets pulled into the software supply chain without obvious runtime symptoms.
Expanded Definition
Dependency resolution is the mechanism a package manager, build tool, or language ecosystem uses to decide which artifact versions become part of a build. The term covers direct dependencies, transitive dependencies, version constraints, lockfiles, registry lookups, and conflict handling. It does not mean simply “installing packages”; it is the selection logic that determines what will be installed.
Security teams treat this step as part of software supply chain control because the chosen version can differ from what developers expected. A seemingly minor change in resolution may pull in a vulnerable library, a maliciously published package, or a different module from an unintended registry. In practice, the risk often appears before code is executed, which is why dependency resolution is a build-time trust decision rather than a runtime convenience.
There is broad consensus that deterministic resolution is desirable, but the exact balance between reproducibility, freshness, and compatibility still varies by ecosystem. A common misunderstanding is assuming that a dependency declared in source control is the same thing as the dependency actually built; the resolver is the point where that assumption can fail.
Examples and Use Cases
Dependency resolution shows up in many ordinary engineering workflows, but each one can alter supply chain trust in different ways. The same package name may resolve differently depending on registry settings, semver ranges, platform constraints, or the age of a lockfile.
- A JavaScript build resolves a caret version range to a newer transitive release, changing the installed code without a source change.
- A Python project installs from an internal mirror, but a registry configuration mistake sends the resolver to a public source instead.
- A Java or .NET build chooses between overlapping artifacts, and the selected version determines whether a known flaw is introduced or avoided.
- A locked build repeats the same dependency graph for release engineering, trading freshness for reproducibility and auditability.
- A monorepo uses separate dependency rules for different services, so one service’s safe resolution does not guarantee another service’s safety.
For practitioners, the main trade-off is usually determinism versus update velocity. More permissive resolution can reduce friction during development, but it also increases the chance that hidden transitive changes enter the pipeline unnoticed.
Security Implications
When dependency resolution is weakly controlled, the failure is often silent: the build still succeeds, but the software graph changes. That can introduce vulnerable libraries, incompatible versions, or packages with unexpected provenance. Because the resolver operates before deployment, teams may not see a problem until vulnerability scanning, testing, or incident response reveals that the delivered artifact is not the one they intended to ship.
Another consequence is blast radius. A single poisoned or mistyped dependency can affect every downstream build that trusts the same package manager, registry, or mirror. This makes resolution policy a supply chain control, not just a developer convenience.
The observable symptoms are usually indirect: unexplained build drift, repeated dependency mismatches across environments, or sudden appearance of a package that was never consciously approved. A practitioner should treat those signs as evidence that the build graph is not fully under control.
Domain and Governance Relevance
In software supply chain governance, dependency resolution defines what the organisation actually consumes, not just what it asked for. That distinction matters for security review, software bill of materials accuracy, and change control. If the resolved graph is not predictable, then approval decisions, vulnerability analysis, and provenance assertions all rest on unstable ground.
For identity and privileged-access programs, the relevance is indirect but real when build systems, package managers, or automation agents are allowed to fetch and install code. In that case, the resolver becomes part of the trust boundary around non-human execution, because the build identity is effectively making supply chain decisions on the organisation’s behalf. NHIMG’s guidance on OWASP Non-Human Identity Top 10 is useful where build automation, service access, and dependency sourcing are governed together.
The practical governance question is whether teams can explain why a given artifact version was selected, reproduced, and approved. Without that answer, dependency resolution is functioning as an uncontrolled change mechanism.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 15 — Service Provider Management | Dependency resolution often relies on external package sources and mirrors. |
| Recommendation — Verify and govern third-party package sources used during builds. | ||
| NIST CSF 2.0 | SR-3 — Supply Chain Controls Are Implemented | Resolution determines which supply-chain components enter the build. |
| Recommendation — Implement supply chain controls that constrain what dependency resolvers can pull in. | ||
| MITRE ATT&CK | T1553.002 — Subvert Trust Controls: Code Signing Policy Modification | Resolution abuse can bypass trust assumptions around delivered artifacts. |
| Recommendation — Monitor for trust-path abuse that alters which software artifacts are accepted. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Build automation and package access often hinge on non-human credentials. |
| Recommendation — Restrict build-time credentials that authorize dependency retrieval and installation. | ||
