PyPI's New Security Tab Grades Releases by Attestation, and Says What It Cannot Prove

PyPI project pages now carry a Security tab that tells a reader whether each release file was built where the project says it was. The PyPI team's post, dated November 6, 2026, finishes a redesign announced in July 2026, with design work by Kabu Creative and funding from the Open Source Security Foundation (OpenSSF).

The tab reads attestations, signed statements attached to individual files. It cannot tell you whether a package is safe, and PyPI says so: "No provenance does not necessarily indicate that a release or release file is malicious."

How PyPI sorts a release

PyPI "calculates each release's provenance state by checking whether each release file has an attestation". Two kinds count. A PyPI Publish attestation confirms that a Trusted Publisher uploaded the file. A SLSA Build Provenance attestation ties the file to a source commit, a build platform and build instructions.

State	Meaning
Full Provenance	Every file in the release has an attestation
No Provenance	No file has one
Incomplete	Some files are attested and others are not
Inconsistent	Files in one release come from different build systems or repositories

Two further warnings compare a release with the project's history. "Change of" fires when a release comes from a different repository or workflow than the previous one. "Loss of" fires when a project that used to publish with attestations uploads without them. Help Net Security's Anamarija Pogorelec, a senior staff writer, notes that a workflow change "often has a legitimate explanation", such as a rename or a repository move, but "may signal a compromised pipeline or an account takeover".

What else changed on the page

Warnings now sit at the top of the project page, with quarantine banners taking precedence over yanked, archived and pre-release ones. The release files tab gains search, filtering and per-file provenance. Files uploaded more than 14 days after the release timestamp get an orange warning icon, but only on releases before July 2026, when PyPI began rejecting late files outright.

The release history tab now shows file count, provenance state and release status for every version. PyPI also expanded its package security guide and published a case study in the OpenSSF Attestations Style Guide.

How many projects can show Full Provenance

The signal is only as useful as the share of uploads that produce it. LWN's Joe Brockmeier reported on June 9, 2026 from a talk at Open Source Summit North America by Mike Fiedler, the PSF's safety and security engineer for PyPI. Fiedler put trusted publishing at about 10% of new uploads in February 2024 and more than 36% as of May 2026, with more than 2.2 million files published that way since April 2023.

1. February 202410 %
2. May 202636 %

Source: Mike Fiedler talk at Open Source Summit North America, as reported by LWN on June 9, 2026 (May 2026 value is 'more than 36')

Those numbers are about uploads, not downloads, and they describe the trusted-publishing path rather than attestations alone. Neither LWN nor the PyPI post gives a share of installs that would show Full Provenance today.

The limits the maintainers state themselves

According to LWN, Fiedler said verification "is not built into the package managers yet", so a plain pip install does not check any of this. He said PyPI is trying to present attestations so they are "not too promising that this is 100% secure", and that the claim is only that a file "was not tampered with in flight". He added: "we're not saying what's inside is good for you." Homebrew already validates Sigstore attestations, per the same report.

Nicole Harris, a PyPI design contributor, is quoted by Help Net Security as saying that a missing attestation "only means its origin can't be cryptographically verified". She is on the PyPI side, so that is the project describing its own feature.

The practical reading is narrow. A "Loss of" or "Change of" banner on a package you depend on is a reason to look at the maintainer history and the repository before upgrading. A clean Full Provenance badge says the file came from the named workflow, and says nothing about whether the source in that workflow was clean. For another supply-chain case, see the Arara Message breach, and for developer tooling that reads your code, Alibaba's OpenCodeReview.