A resolved dependency is a specific input artifact identified by immutable digest at build time. It matters because registry tags can move, but digests pin the exact model, dataset or package that was consumed when the output was created.
What a resolved dependency means in practice
A resolved dependency is the exact build input that was consumed, not just the package or model name. By binding that input to an immutable digest, teams preserve a verifiable record of what actually entered the build, even when upstream tags or labels later change.
This matters because dependency names are often human-friendly pointers, while digests are the stable identity of the artifact. A tag can be retargeted, republished, or overwritten, but a digest keeps the resolved object fixed for reproducibility, traceability, and security review.
Why digests matter more than moving tags
Resolved dependencies reduce ambiguity in software and model supply chains. If a build references a mutable tag, two builds with the same manifest can silently consume different inputs; if it references a digest, the build can be reconstructed against the same artifact content.
That distinction is especially important for packages, datasets, container layers, and model artifacts, where the dependency name is only an alias. The digest is what lets teams answer, with confidence, what was actually used when the output was produced.
How resolved dependencies support reproducibility and auditability
In security and governance workflows, resolved dependencies become the evidence layer behind a release. They support rebuilds, change comparison, incident review, and provenance checks because they tie the output to a specific immutable input rather than to an upstream moving target.
They also make dependency drift visible. If the same logical dependency name resolves to a different digest over time, that change is meaningful and should be treated as a supply-chain event, not a harmless metadata update.
When a build pipeline records resolved dependencies well, reviewers can compare manifests, attestations, and artifact inventories without guessing which version label was in effect. That makes forensic analysis and release governance much more reliable.
Where resolved dependencies can fail
Resolved dependencies are only useful if the system that records them is trustworthy and complete. If the build resolves from an unpinned source, a compromised registry, or an unverified artifact mirror, the digest may faithfully describe a malicious input instead of a legitimate one.
OpenSSF publishes supply-chain guidance and tooling that help teams harden the process of identifying and verifying what enters a build. That broader supply-chain focus is relevant because a resolved dependency only protects you when the upstream selection process is controlled.
Failure mechanism: an attacker or careless publisher changes the content behind a mutable tag, or inserts a look-alike artifact into the resolution path, and the build consumes a different payload while the dependency name appears unchanged.
Impact: the resulting output may be non-reproducible, poisoned, or difficult to investigate, and teams may not discover the compromise until after deployment or model use.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Provenance | Resolved dependencies are part of verifiable build provenance and artifact integrity. |
| Recommendation — Record immutable digests and verify artifact provenance for every build input. | ||
| CIS Controls v8 | CIS-15 — Service Provider Management | Resolved dependencies often rely on third-party registries and package sources that must be governed. |
| Recommendation — Evaluate third-party dependency sources and restrict trusted supply-chain providers. | ||
| NIST SP 800-53 Rev 5 | SR-11 — Component Authenticity | Digest-pinned dependencies support authenticity checks for components entering the build. |
| SA-12 — Supply Chain Protection | The term directly concerns controlled, traceable acquisition of build dependencies. | |
| Recommendation — Validate component authenticity before accepting resolved build inputs. Protect the software supply chain by pinning and verifying resolved artifacts. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Resolved dependencies are an architectural control for reproducible and trustworthy builds. |
| Recommendation — Design builds to consume immutable, verifiable dependencies instead of mutable aliases. | ||
Practitioner Guidance
Why practitioners should care: Treat resolved dependencies as part of build provenance, not as convenience metadata. If the digest is missing, stale, or not checked against the artifact actually consumed, the record cannot support a reliable security or audit conclusion.
What to watch for: Look for pipelines that still reference tags, implicit latest versions, or unpinned external inputs. Those patterns weaken the value of the resolution record because they let the input change without changing the manifest.
Practitioner takeaway: The safest dependency record is one that can be independently verified back to an immutable artifact, a controlled source, and a repeatable build step.
Related resources from NHI Mgmt Group
- What breaks when a malicious dependency is resolved during npm install?
- When does a dependency compromise become an identity incident?
- How should teams slow down malicious dependency updates without breaking delivery?
- What is the difference between automating dependency updates and granting them blind trust?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org