Provenance verifies where a package was built and from which source, while Subresource Integrity verifies that the file a browser loads has not changed since it was hashed. They address different trust points in the supply chain. Organisations that use both gain stronger protection across package publishing and script delivery.
Why This Matters for Security Teams
Provenance and Subresource Integrity solve related but different trust problems, and confusing them leaves gaps at two separate stages of software delivery. Provenance is about build origin and traceability, helping teams verify that a package came from an expected source and was produced through a controlled process. SRI is about delivery-time tamper detection, helping a browser reject a file whose content no longer matches the expected hash. That distinction matters in modern supply chains where packages, scripts, and build artefacts can be altered independently.
Security teams often assume one control covers the other, but that is rarely true in practice. Provenance does not stop a CDN, tag, or third-party script from being modified after publication. SRI does not tell you whether a package was built by an authorised pipeline or whether the source repository itself was compromised. The NIST Cybersecurity Framework 2.0 is useful here because it encourages teams to think in terms of governance, supply chain assurance, and continuous verification rather than a single point control. In practice, many security teams encounter trust failures only after a build pipeline or browser-delivered asset has already been abused, rather than through intentional supply chain validation.
How It Works in Practice
Provenance is usually generated by the build system and attached to the software artefact as metadata. It can record the builder identity, source revision, dependency inputs, and the build steps that produced the output. The practical goal is to make it possible to answer, “Who built this, from what, and under what conditions?” That is especially valuable for package registries, CI pipelines, and internal release processes where integrity alone is not enough.
SRI works differently. A publisher computes a cryptographic hash of a specific file, then embeds that hash in the HTML or delivery mechanism. When the browser fetches the file, it recalculates the hash and blocks execution if the content has changed. This is most commonly used for third-party JavaScript and other static assets, and it is closely aligned with browser-side trust enforcement. For implementation guidance, teams can compare their delivery controls with the OWASP Subresource Integrity Cheat Sheet and supply chain practices in SLSA.
- Use provenance to validate build origin, source inputs, and pipeline integrity.
- Use SRI to detect whether a loaded asset has been modified after publication.
- Pair both with dependency pinning and release signing where appropriate.
- Track who can publish, who can change hashes, and who can approve release artefacts.
For broader supply chain governance, the NIST supply chain security guidance helps teams place both controls inside a wider verification model rather than treating them as isolated technical features. These controls tend to break down when assets are dynamically generated or rewritten at the edge because the content being hashed no longer remains stable across delivery paths.
Common Variations and Edge Cases
Tighter integrity controls often increase operational overhead, requiring organisations to balance stronger trust guarantees against release speed and maintenance effort. That tradeoff is especially visible when teams manage many scripts, frequent releases, or heterogeneous build systems.
One common edge case is dynamic content. SRI is strongest for stable, versioned files, but it becomes awkward when a script changes on every request or when a platform injects content at runtime. Another is provenance for multi-stage builds: if a package is rebuilt across several environments, the provenance record must preserve enough detail to remain meaningful, otherwise the trail becomes too vague to support trust decisions. Current guidance suggests treating provenance as stronger when it is produced automatically by a trusted build service and signed, but there is no universal standard for this yet across all ecosystems.
Identity also matters. If the build system, artifact registry, or signing service is controlled by a compromised account, both provenance and SRI can be undermined upstream. That is where NHI governance becomes relevant: service accounts, CI tokens, signing keys, and release automation identities need the same scrutiny as human administrative access. Teams should also align browser-delivered assets with threat modelling in CISA supply chain guidance and the broader assumptions in SLSA. The practical takeaway is to use provenance for build trust and SRI for delivery trust, then secure the identities that operate both.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATLAS address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-1 | Supply chain risk governance fits provenance and asset integrity decisions. |
| OWASP Agentic AI Top 10 | Agentic tooling can alter build or delivery paths that these controls must protect. | |
| NIST AI RMF | AI-assisted build and release workflows need provenance for accountability and traceability. | |
| OWASP Non-Human Identity Top 10 | CI/CD service identities and signing keys are non-human identities that can compromise trust. | |
| MITRE ATLAS | Adversarial tampering with models or artefacts can defeat provenance if build trust is weak. |
Define software supply chain trust requirements and assign ownership for provenance and integrity checks.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
