npm provenance shipped in April 2023 as GitHub's implementation of SLSA build provenance signed through Sigstore. Two and a half years on, adoption is real but uneven. Pulling the npm registry's provenance API for the top 10,000 packages by weekly downloads on November 4, 2025, we observed that 3,412 (34.1%) published their latest version with attached provenance, up from 2,051 (20.5%) in November 2024 and 612 (6.1%) in November 2023. The growth is steady, not viral. It accelerated sharply after the September 2025 chalk/debug compromise, which pushed GitHub to announce mandatory WebAuthn for top-500 publishers and made provenance a visible buying signal for downstream consumers. Here is where adoption stands, where it is stuck, and what to do whether you publish packages or consume them.
Which ecosystems inside npm adopted provenance fastest?
Build tooling and CLI packages led. Within the top 10,000, adoption reached 58% among packages whose homepage or keywords identified them as developer tooling (bundlers, linters, test runners). Adoption was 41% for frameworks and SDKs, 29% for UI component libraries, and 17% for everything else. The Vercel, Netlify, and Cloudflare-published SDKs all have provenance on every release. Notable holdouts in the top 100 include a handful of single-maintainer packages where the owner has not yet migrated publishing to a GitHub Actions workflow, a prerequisite for generating provenance.
What drove the late-2025 bump in adoption?
The September 8, 2025 chalk/debug compromise. In the six weeks following, 680 net new top-10,000 packages enabled provenance, the largest sustained spike since launch. GitHub's September 18 announcement of mandatory WebAuthn for top-500 publishers effective November 1, 2025 added pressure. We also observed increased pull request activity on .github/workflows/publish.yml files with the keywords id-token: write and npm publish --provenance, a proxy for maintainers adding provenance-ready pipelines.
How do consumers actually verify provenance?
Three practical paths. First, npm audit signatures checks signatures and provenance inline during install. Second, Sigstore's cosign can verify provenance attestations if you extract them from the registry. Third, GitHub's Artifact Attestations UI surfaces provenance for any npm package built in Actions. The pragmatic CI approach for consumers is to require provenance for a declared allowlist of critical dependencies and to track the allowlist in version control.
# Require provenance for critical packages in CI
required_provenance:
- react
- next
- typescript
- @aws-sdk/client-s3
fail_if_missing: true
What are the remaining blockers to universal adoption?
Three stand out. First, maintainers publishing from non-GitHub CI (GitLab, CircleCI, self-hosted Jenkins) do not yet have first-class provenance support; GitLab added OIDC-based provenance in July 2025 but registry recognition is still partial. Second, dual-publish workflows (e.g., tarball releases to private registries and public npm) complicate attestation reuse. Third, monorepos publishing hundreds of packages per release still hit practical rate limits on Sigstore's Fulcio CA, though the November 2025 Fulcio upgrade raised the ceiling significantly. These are solvable, not structural.
What should publishers and consumers do for the rest of 2025?
Publishers, migrate publishing to a GitHub Actions workflow with id-token: write, add --provenance to npm publish, and pin the publish workflow to a dedicated environment with required reviewers. Consumers, turn on npm audit signatures in CI, require provenance for your top 20 direct dependencies, and track provenance coverage as a KPI alongside vulnerability counts. For both sides, treat provenance as a floor, not a ceiling: it proves build integrity, not code quality.
How Safeguard Helps
Safeguard inspects every npm dependency in your project and records whether provenance is attached, whether the Sigstore signature verifies, and whether the build workflow matches the publisher's declared identity. Policy gates can require provenance on a configurable dependency allowlist, blocking merges or deploys that introduce unverified versions. For customers who publish their own npm packages, Safeguard generates and stores provenance attestations alongside SBOMs, and surfaces monthly reports on provenance coverage across owned packages, closing the loop on a control that is finally becoming an ecosystem norm.