61/100 top PyPI packages ship full provenance

61 of the 100 most-downloaded packages on PyPI now ship with full provenance. The other 39 — including boto3, the single most-downloaded package on the index — ship with no provenance at all, and not one of the 100 sits in between.

PyPI finished rolling out its redesigned project pages on November 6, with a dedicated security tab that shows, per release, whether every file carries a digital attestation proving where it came from. I wanted to know what that badge actually looks like across the packages everyone installs, so I checked the top 100 by 30-day downloads and read the provenance state off each project's security tab. Same signal the UI shows you, no API tricks — PyPI's JSON API doesn't even expose attestations, so the page is the source of truth.

How I counted

The list is hugovk's top-pypi-packages (30-day download counts, last updated November 1, 2026). For each of the 100 names I fetched pypi.org/project/<name>/ on November 14, 2026 and read the heading inside the page's provenance-status block — the same element that renders the security tab. PyPI defines the states in its November 6 blog post: Full provenance means 100% of the release files carry attestations (PyPI Publish, SLSA Build Provenance, or both); No provenance means none of them do. There are also four warning states — Incomplete, Inconsistent, Change of, and Loss of provenance — for releases that sit in between.

Every page returned 200. Eight pages timed out or failed to parse on the first pass; I re-fetched all eight until each resolved. Final tally: 100 out of 100.

The scoreboard

The distribution is bimodal — all or nothing. Nobody in the top 100 has a half-signed release.

The full-provenance camp is the one you'd expect: requests 2.34.2, cryptography 50.0.2, numpy, pandas 3.1.1, scipy 1.18.1, pip 26.3, pydantic, pytest, aiohttp, uvicorn 0.54.0, openai 3.51.0. The plumbing of the ecosystem mostly signs its work now.

The no-provenance camp is where it gets uncomfortable:

The pattern isn't "small projects can't afford it." It's maintainers who publish through their own release automation instead of PyPI's Trusted Publishing flow. ruff is an Astral project with serious release engineering; its latest release simply carries no attestations. setuptools builds most of the ecosystem and doesn't sign its own releases. The tool that builds the packages doesn't use the mechanism that proves where packages came from.

What "no provenance" does and doesn't mean

PyPI is explicit about this, and it's worth quoting the shape of it: no provenance does not mean a release is malicious. It means the file's origin cannot be cryptographically verified. An attestation ties a wheel back to a specific source commit and build workflow; without one, you're trusting the maintainer's account, their CI, and PyPI's upload path — which is exactly the chain that account-takeover and workflow-compromise attacks target. The warning states exist for when that chain looks off (a release that used to be signed and suddenly isn't, files from two different repos), and zero of the top 100 currently trip any of them. The signal is clean; the coverage is what's thin.

Two caveats on my count. First, I checked the latest release shown on each project page, so a package that signs most releases but shipped one unsigned version would show up as "no provenance" — the state is per-release, not per-project. Second, the top-100 list is 30-day downloads, so it overweights infrastructure packages and underweights the long tail, where adoption is almost certainly worse. If 39% of the top 100 can't prove origin, the median package on PyPI is doing worse, not better.

The takeaway

The badge works. When a package has full provenance you can click through to the attestation metadata and the transparency log and see the exact commit and workflow that produced the wheel. The problem is that the badge only covers 61% of the packages that matter most, and the missing 39% includes the AWS SDK, the most popular web framework, the most popular HTTP client, and the tool that builds everything else.

If you maintain a package, the fix is one configuration change: publish through Trusted Publishing with a publisher that generates attestations. If you install packages, the security tab is now one click away on every project page — check it before you pip install the thing that runs in production.

Sources: PyPI blog, "PyPI's redesigned project pages with clearer security signals are now live" (November 6, 2026); PyPI package security documentation on provenance; hugovk/top-pypi-packages 30-day download data (last updated November 1, 2026). All 100 provenance states were read from the live project pages on November 14, 2026; the per-package results are in the author's audit log. "No provenance" is PyPI's term for a release with no attested files, and per PyPI's own documentation it is not evidence of maliciousness.