Resolution-time trust enforcement is the practice of evaluating package safety before a dependency is selected for install. It shifts security into the dependency solver or registry policy layer, so malicious versions are excluded before they can enter a build, rather than being found after download or execution.
Expanded Definition
Resolution-time trust enforcement moves trust decisions earlier than traditional software supply chain checks. Rather than allowing a package manager to resolve any available dependency and then scanning the result, the policy layer evaluates whether a version, publisher, signature, provenance claim, or metadata condition is acceptable before selection happens. This makes the resolver itself part of the security control plane, so unsafe options can be excluded before they ever reach a build graph.
Definitions vary across vendors and package ecosystems, because some implementations enforce policy in the registry, some in the client resolver, and others in an internal artifact proxy. The concept is still evolving, but the core idea is consistent: trust is asserted at selection time, not after download. That distinction matters for modern build systems that rely on transitive dependencies, ephemeral CI jobs, and automated update agents. The closest governance framing is reflected in the NIST Cybersecurity Framework 2.0, especially where supply chain risk must be handled as part of secure acquisition and change control.
The most common misapplication is treating post-install scanning as resolution-time enforcement, which occurs when organisations only inspect artifacts after the dependency solver has already chosen and cached them.
Examples and Use Cases
Implementing resolution-time trust enforcement rigorously often introduces compatibility constraints, requiring organisations to weigh supply chain safety against package availability and developer velocity.
- A build pipeline blocks dependency versions that lack trusted provenance attestations, forcing the solver to choose a known-good release instead of the newest one.
- An internal package proxy allows only signed artifacts from approved publishers, preventing developers from resolving typosquatted or repackaged dependencies.
- A policy engine rejects versions with known malicious metadata, such as abandoned maintainers or compromised release channels, before install begins.
- An enterprise CI system integrates resolver policy with SBOM generation so that dependency selection and audit evidence are produced together.
- A platform team uses registry rules to prevent automated bots from introducing unreviewed pre-release packages into production builds.
For dependency trust signals, teams often combine repository policy with source integrity controls from SLSA and package integrity guidance from PyPI ecosystem practices, though no single standard governs every language stack yet. In practice, the control has to sit where resolution decisions are made, not where artifacts are merely observed.
Why It Matters for Security Teams
Security teams care about resolution-time trust enforcement because the earliest point of control is often the only point where malicious dependencies can be stopped without downstream remediation. Once an unsafe package enters a build, it can be cached, mirrored, tested, deployed, and inherited by other projects, turning a single resolver event into a broad supply chain exposure. This is especially important in environments that rely on NHI-like automation, where bots, CI runners, and agentic build tools can make dependency choices at machine speed.
The control also sharpens governance around provenance, supplier trust, and change management. When resolution is policy-driven, teams can define which signatures, issuers, registries, or metadata conditions are acceptable before software is assembled. That makes the control complementary to broader software supply chain programs and to secure development expectations in CISA SSDF. It is less about reacting to a bad package and more about preventing the wrong artifact from ever becoming part of the system of record.
Organisations typically encounter the operational impact only after a poisoned dependency has been pulled into a release pipeline, at which point resolution-time trust enforcement becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC | Supply chain governance covers controlling trusted software sources and dependency risk. |
| NIST SP 800-53 Rev 5 | SI-7 | Integrity controls relate to preventing malicious code and unsafe components from being accepted. |
| ISO/IEC 27001:2022 | A.5.21 | ICT supply chain security guidance supports trusted sourcing and component control. |
| NIST AI RMF | AI RMF is relevant where automated agents or AI tooling choose dependencies on behalf of teams. | |
| OWASP Non-Human Identity Top 10 | NHI governance applies when CI bots and build agents resolve packages using machine identities. |
Assign accountability for automated dependency-selection decisions made by AI-enabled tooling.
