Strict resolution is a dependency control that fails the install or build when the requested artifact cannot be verified as coming from the intended source. For repository-based dependencies, strict resolution reduces ambiguity by turning hidden source drift into an explicit error that teams can investigate.
Expanded Definition
Strict resolution is a dependency integrity control used in software build and package workflows when the source of an artifact must be unambiguous. Rather than allowing a resolver to silently substitute a different repository, mirror, or cached copy, strict resolution requires the build to fail if the requested artifact cannot be verified as coming from the intended source. This makes source drift visible at the point of installation or compilation, where it can still be investigated and corrected.
In practice, strict resolution sits between package management and supply chain assurance. It is not the same as general pinning, because pinning fixes a version while strict resolution also constrains provenance and source selection. It is also different from policy-based allowlisting, which may permit more than one source path if trust criteria are met. The concept aligns with governance guidance in the NIST Cybersecurity Framework 2.0, especially where organisations need repeatable control over software acquisition and integrity checks. The most common misapplication is treating version pinning as strict resolution, which occurs when teams lock a dependency version but still allow unverified mirrors, fallback registries, or transparent substitutions.
Examples and Use Cases
Implementing strict resolution rigorously often introduces build fragility at first, requiring organisations to weigh supply chain assurance against the operational cost of failures when a dependency source changes unexpectedly.
- A CI pipeline rejects a package when the primary registry is unavailable and the resolver tries to fetch from an unapproved mirror instead of failing closed.
- A monorepo build fails because a transitive dependency was republished from a different namespace, triggering investigation before the change reaches production.
- An engineering team requires verified provenance for internal artifacts so that cached binaries cannot silently replace repository-originated packages during rebuilds.
- A release process blocks installation when checksum or source assertions do not match the declared repository, reducing the risk of hidden dependency drift.
- A security review uses guidance from the NIST Cybersecurity Framework 2.0 to map dependency source controls to broader software integrity expectations.
Why It Matters for Security Teams
Security teams care about strict resolution because dependency ambiguity is a supply chain risk, not just a developer inconvenience. When build systems accept substitutions without explicit approval, attackers can exploit registry compromise, namespace confusion, or dependency hijacking to introduce malicious code that appears legitimate. Strict resolution reduces that exposure by making the intended source part of the control boundary, which supports repeatable builds, auditability, and incident triage.
This matters especially in environments that depend on automated delivery, where software composition is updated frequently and human review does not scale. Strict resolution also helps identity and access governance around software infrastructure, because package registries, signing services, and build agents behave like non-human identities that need tightly scoped trust. Where organisations adopt broader supply chain controls, the NIST guidance on cybersecurity outcomes provides a useful lens, and teams may also look to NIST Cybersecurity Framework 2.0 for governance alignment. Organisations typically encounter the full impact only after a build succeeds with the wrong dependency source, at which point strict resolution becomes operationally unavoidable to contain the drift.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-6 | Integrity mechanisms and software provenance align with protecting data and software from unauthorized change. |
| NIST SP 800-53 Rev 5 | SA-12 | Supply chain protection controls address trusted sources for acquired components and artifacts. |
| ISO/IEC 27001:2022 | A.5.19 | Information security in supplier relationships covers assurance over externally sourced components. |
Enforce source verification so dependency integrity is checked before software is built or released.
