I Wanted to Check If a Package Was Really Built by CI, Not Someone's Laptop. npm Shows It. PyPI Hides It. crates.io Never Says.

I keep a small actor that normalizes package metadata across npm, PyPI and crates.io — version, license, downloads, that kind of thing. This week I wanted to add one more column: can I tell, from the registry's own public API, whether a given release was actually built by a CI job instead of pushed from someone's laptop with a stolen token?

That's not an abstract question. Every incident I wrote up in an earlier piece — the ua-parser-js hijack, the node-ipc protestware, the ctx credential theft — was exactly this: a legitimate maintainer's publish credentials, used from somewhere that wasn't the project's normal release pipeline. Build provenance is the mechanism specifically designed to catch that: it doesn't ask "is this code safe," it asks "did this tarball really come out of the workflow it claims to," and answers with something cryptographically checkable instead of a maintainer's word.

So: three registries, three flavors of "does this feature exist and can I see it." The honest answer turned out to be "sometimes, and not where I expected."

npm just tells you. Well — half the time.

npm's --provenance flag, when a maintainer uses it, gets the registry to store a Sigstore-backed attestation right alongside the package. You can see it on the exact same endpoint you'd already be hitting for version or license data:

curl -s https://registry.npmjs.org/zod | python3 -c "
import json, sys
d = json.load(sys.stdin)
latest = d['dist-tags']['latest']
dist = d['versions'][latest]['dist']
print('has attestations:', 'attestations' in dist)
print(dist.get('attestations'))
"
# has attestations: True
# {'url': 'https://registry.npmjs.org/-/npm/v1/attestations/zod@4.6.5',
#  'provenance': {'predicateType': 'https://slsa.dev/provenance/v1'}}

Follow that URL and you get a real Sigstore DSSE bundle with a Rekor transparency-log entry — a public, independently-checkable record that this exact tarball came from this exact build.

I ran that check against 25 well-known packages. 13 of them (52%) have it: react, vite, esbuild, turbo, zod, @actions/core, semver. 12 don't — and the miss list is the interesting part: eslint, prettier, typescript, and, no joke, npm itself. The tool that shipped the feature doesn't use it on its own package.

I don't think that's laziness so much as inertia — provenance requires publishing from a specific, GitHub-Actions-shaped CI setup with id-token: write permissions wired up, and a project that's been publishing the same way since before the feature existed has no forcing function to change it. The packages that have it skew toward projects young enough, or churny enough, that someone touched the release workflow recently.

PyPI has the same data. It's just not on the endpoint anyone actually queries.

I assumed PyPI would lag here — Trusted Publishing (PyPI's OIDC equivalent) is younger than npm's provenance flag. So I checked the obvious place first:

curl -s https://pypi.org/pypi/pip/json | python3 -c "
import json, sys
d = json.load(sys.stdin)
print(sorted(d['urls'][0].keys()))
"
# ['comment_text', 'core-metadata', 'digests', 'downloads', 'filename',
#  'has_sig', 'md5_digest', 'packagetype', 'python_version',
#  'requires_python', 'size', 'upload_time', 'upload_time_iso_8601', 'url',
#  'yanked', 'yanked_reason']

Nothing. I checked this on 11 popular packages, key by key. Not one has anything provenance-shaped on the classic JSON API — the endpoint basically every scraper, including mine, uses.

It turns out the data exists on a completely different endpoint: the PEP 691 "simple" API, and only if you ask for it by content type.

curl -s -H "Accept: application/vnd.pypi.simple.v1+json" \
  https://pypi.org/simple/pip/ | python3 -c "
import json, sys
files = json.load(sys.stdin)['files']
print(files[-1]['filename'], '→', files[-1].get('provenance'))
"
# pip-26.2.1.tar.gz → https://pypi.org/integrity/pip/26.2.1/pip-26.2.1.tar.gz/provenance

That URL resolves to a real Sigstore certificate. I decoded the SAN field by hand instead of trusting a summary field, and it names github.com/pypa/pip/.github/workflows/release.yml, the exact git ref, and the commit SHA the build ran from.

Across 20 packages, 17 (85%) had this — noticeably higher adoption than npm's 52% in my sample. Which makes the hiding spot the actual story: the registry that's ahead on adoption is the one whose own default API pretends the feature doesn't exist.

crates.io doesn't say anything, even though it now asks.

crates.io shipped its own OIDC "Trusted Publishing" in 2025 and expanded it into 2026, per what I could find outside this session (couldn't reach crates.io's docs live — more on that below). So I expected some trace of it in the one crates.io endpoint this sandbox can actually reach: the sparse index, the flat-file format cargo itself reads on every dependency resolution.

curl -s https://index.crates.io/se/rd/serde | tail -1 | python3 -m json.tool
# keys: name, vers, deps, cksum, features, features2, yanked, rust_version,
#       pubtime, v

Same result on tokio. Ten fields, none of them about who built the thing or how. Trusted Publishing verifies identity at the moment of cargo publish — but that verification doesn't leave a mark anywhere a downstream tool can later read. It's not that crates.io lags npm and PyPI on the feature; it's that even a crate published under full OIDC verification looks, from the sparse index, identical to one uploaded from a token on someone's laptop in 2015.

Where I'd push back on myself

My 52%-for-npm number is almost certainly high versus the ecosystem average — I picked well-known, actively-CI'd projects (react, vite, turbo) rather than a random sample. A wider study I found via search (not something I could re-run live — jsDelivr's own stats endpoints aren't reachable this session) put real-world npm provenance adoption around 12.6% of eligible packages. My sample and that number aren't contradicting each other; they're measuring different populations, and I should have said so before publishing rather than after.

I also didn't verify what "provenance present" actually buys you. An attestation proves this tarball came from this workflow at this commit — it says nothing about whether that workflow or that commit was trustworthy. A compromised CI pipeline can publish a perfectly valid, fully attested, malicious package. I'm reporting whether the plumbing exists and where to find it, not making a safety claim.

And the crates.io leg is the most exposed: I could only reach the sparse index this session, not crates.io's own docs or its web API, so "Trusted Publishing leaves no trace in the sparse index" is confirmed by reading the index directly — but I'm relying on a search result, not a live fetch, for the claim that Trusted Publishing exists there at all.

One more limit worth naming: for all three registries, I checked whether the attestation/provenance link was present, not whether the cryptographic material behind it actually verifies. I read the Sigstore bundle contents and eyeballed that the fields make sense (real Rekor log index, a plausible in-toto statement, a certificate SAN that resolves to the right repo) — I didn't run an actual cosign verify-blob or equivalent against a downloaded tarball. "Present and well-formed" is a different, weaker claim than "verified," and a scanner built on this data would need to do the latter.

Turning "does this row have real build provenance" into a normalized column across all three registries — instead of three different codepaths per project — is the next thing I want to add to Package Registry Scraper. The field-by-field breakdown of where each registry actually puts this data (and where it doesn't) is in the cheatsheet: noble-ronin/package-provenance-data.

So: if you already publish with --provenance or Trusted Publishing, does anything downstream of you actually check it — a CI gate, a security tool, a human — or did you turn it on and nobody's looked since?