Notifications
Clear all
Topic starter
02/08/2026 12:07 pm
TL;DR: NPM provenance is designed to cryptographically link a published package to a specific source commit and build pipeline, but adoption is still limited, with only 26 of 205 highly downloaded jsDelivr packages using it in the article’s sample, according to Exaforce. Without registry and client-side enforcement, package trust remains a supply chain problem, not a solved control.
NHIMG editorial — based on content published by Exaforce: Npm provenance: bridging the missing security layer in JavaScript libraries
By the numbers:
- Among the 2,000 most downloaded packages on jsDelivr, 205 packages have a public GitHub repository and directly publish to npm using GitHub Workflows.
- Only 26 (12.6%) of these packages have enabled provenance.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: What breaks when package provenance is not enforced?
A: Without enforced provenance, package consumers cannot reliably tell whether a dependency came from the expected source or from a compromised build path.
Q: Why do CI/CD identities matter in package supply chain security?
A: CI/CD identities often hold the permissions needed to build, sign, and publish software artifacts.
Q: How do security teams know if provenance controls are actually working?
A: Look for two signals: packages are rejected when provenance is absent or mismatched, and release workflows only succeed from approved source commits and runners.
Practitioner guidance
- Require provenance for critical packages Set publish-time policy for packages that affect authentication, deployment, or customer-facing code paths.
- Harden maintainer and pipeline identities Treat GitHub, GitLab, and CI runner credentials as privileged identities.
- Verify package origin at install time Add dependency checks in CI that fail builds when provenance is missing or does not match the expected repository and commit.
What's in the full article
Exaforce's full post covers the operational detail this post intentionally leaves for the source:
- Workflow examples for enabling NPM provenance in GitHub Actions and package.json release pipelines
- Client-side package verification script details for checking individual package attestations
- Subresource Integrity implementation guidance for JavaScript loaded from CDNs
- Registry and platform policy ideas for mandatory provenance on high-impact packages
👉 Read Exaforce's analysis of NPM provenance gaps in JavaScript libraries →
NPM provenance and package trust: what should teams change now?
Explore further
02/08/2026 1:11 pm
Provenance is only as strong as the identity that signs the build. The article correctly frames provenance as a source-to-artifact integrity control, but its assurance depends on the security of maintainer accounts, CI runners, and pipeline secrets. In NHI terms, the build system is an identity plane, not just an automation layer. If those credentials are exposed, provenance can legitimise bad code rather than stop it. Practitioners should therefore govern publishing identities with the same care as privileged human access.
A question worth separating out:
Q: What is the difference between provenance and Subresource Integrity?
A: 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.
👉 Read our full editorial: NPM provenance gaps leave JavaScript supply chains exposed
