GitHub announced on Thursday that npm packages exceeding one million weekly downloads must publish with build provenance attestations starting March 2, 2027. Provenance links a published artifact to the exact source commit and the workflow that built it, signed through Sigstore, so a consumer can verify the tarball came from the repository it claims rather than from a maintainer's laptop or an attacker with a stolen token. Roughly 3,100 packages meet the threshold today and about 41 percent already publish provenance voluntarily. The rest have nineteen months. Packages that miss the deadline will not be removed, but new versions will be rejected until they comply.
What provenance proves and what it does not
An attestation records the source repository, commit SHA, workflow file, and runner environment that produced an artifact, signed by an identity Sigstore verifies against the CI provider. Verification tells you the package on the registry corresponds to code you can read on GitHub. That defeats a large family of attacks: stolen publish tokens, compromised maintainer accounts publishing from elsewhere, and registry-side tampering. It is the most valuable control available for this ecosystem relative to what it costs to adopt.
It does not tell you the code is safe. A maintainer who commits malicious code to their own repository and builds it through a proper workflow produces a perfectly valid attestation. The 2024 xz backdoor would have carried provenance. What provenance buys is a shift from trusting a publishing credential to trusting a repository and its review process, which is a considerably better place to put trust and is still trust.
Why the download threshold
GitHub chose the one million weekly download line for practical reasons. Below it, the maintainer population is enormous and largely unpaid, and imposing a CI requirement on hobbyists publishing from a laptop would break the ecosystem's on-ramp. Above it, packages are typically maintained by organizations or funded individuals with CI already in place, and the blast radius of a compromise justifies the burden.
The threshold creates an obvious gap. Attackers will target packages just below it, and dependency chains mean a compromised package with 800,000 weekly downloads can reach the same systems as one with two million. GitHub's security lead acknowledged this and said the threshold will lower over time as tooling improves, with a stated intent to reach every package eventually. Critics point out that stating an intent is not a schedule.
The story is rarely the launch. It is what breaks, what ships, and who owns the mess at 2 a.m.
The maintainer burden
For a package already publishing from GitHub Actions, enabling provenance is one line in a workflow file plus an id-token permission. That covers most of the affected packages. The difficult cases are packages published from other CI systems, packages built on maintainer machines because they require hardware npm's runners lack, and packages whose build involves manual steps for legitimate reasons.
GitLab CI, CircleCI, and Buildkite all support the necessary OIDC token exchange, so provenance from those systems works. Self-hosted runners are the harder case, since the attestation's value depends on the runner being trustworthy and GitHub cannot vouch for a machine in someone's basement. The policy accepts self-hosted runners with a marker in the attestation, leaving consumers to decide what that is worth. Several security researchers argued that is too permissive and that a self-hosted attestation proves little.
What consumers should do with this
Publishing provenance accomplishes nothing if nobody verifies it. npm audit signatures checks attestations for installed packages and almost nobody runs it, because it is a separate command producing output that is hard to act on. The more useful integration is at install time, and npm 12 will add a configuration option that fails an install when a package above the threshold lacks provenance, defaulting to warn in 2027 and to fail in 2028.
Organizations with an internal registry proxy have a better lever available now. Verdaccio, Artifactory, and Nexus can all be configured to reject artifacts without valid attestations, which enforces the policy at the boundary rather than per developer. A platform engineer at a large retailer said that switching that on surfaced eleven packages in their dependency tree without provenance, all of which had alternatives, and that the exercise took a week and materially improved their software bill of materials story.
The broader ecosystem movement
PyPI has published provenance support since 2024 with voluntary adoption sitting around 19 percent of new uploads. RubyGems and crates.io both have implementations. None has imposed a requirement, and all of them are watching what happens here. If npm's deadline passes without breaking the ecosystem, expect the others to follow within a year, and expect the European Union's Cyber Resilience Act enforcement to start citing provenance as an expected practice for commercial software.
The counterweight is centralization. Sigstore's transparency log and certificate authority are operated by a nonprofit with funding from a handful of large companies, and making them a mandatory dependency for publishing to the largest package registry gives them enormous structural importance. The Sigstore project has been thoughtful about governance and the concern is legitimate. A registry requirement that depends on one nonprofit's uptime is a new single point of failure in exchange for removing an older one.
Skarvonix will keep following this beat with reporting grounded in how systems behave outside the launch keynote.
- Open Source
- Zero Trust
