PyPI project pages get dedicated security tab and provenance warnings

PyPI has completed a broad redesign of its project pages, headlined by a new security tab that shows whether release files carry cryptographic attestations and raises warnings when a package's provenance looks off. According to a post on the Python Package Index blog, the work — first announced in July and shaped by user research with Python community members — is now live across the site.

A dedicated security tab

The centerpiece is a security tab on every project page. It reports a release's overall provenance state alongside per-file attestations, giving developers one place to check where release files actually came from.

PyPI introduced digital attestations in 2024 to give each release file a cryptographically verifiable origin record. Two kinds are supported, the blog explains: PyPI Publish attestations, which confirm a file was published through a Trusted Publisher, and SLSA Build Provenance attestations, which tie a file to a specific source commit, build platform and build instructions. Attestation metadata can be inspected directly in the interface, with a link out to the transparency log for more detail.

A release usually lands in one of two states. "Full provenance" means every file in the release carries an attestation. "No provenance" means none do, which is typical for older releases or projects that have not set up Trusted Publishing. The PyPI team stresses that absent provenance does not imply a release is malicious — it means the file's origin cannot be verified cryptographically — and suggests leaning on surrounding signals such as the maintainers' track record, their usual release behavior and activity in the source repository.

Warnings when provenance looks wrong

Between those two states sit four warnings designed to catch files that may not have come from a project's maintainers, for instance after an account or publishing-workflow takeover:

• Incomplete provenance: some files in a release carry attestations while others do not, such as wheels pushed through Trusted Publishing while the source tarball went up with a conventional API token.
• Inconsistent provenance: one release mixes files built on different systems or drawn from different source repositories.
• Change of provenance: files come from a different repository or workflow than earlier releases did — often legitimate, such as a repo migration, but potentially a sign of a compromised pipeline.
• Loss of provenance: a project that used to publish with attestations has switched to uploads without them.

The blog notes that most warnings have innocent explanations, but each is worth investigating before installing — checking release notes, the issue tracker, or the project's official channels to confirm an infrastructure change was planned.

Redesigned project and release pages

The project detail page was reworked to support the new signals. Provenance warnings now sit at the top of the page next to existing banners for yanked releases, archived projects and pre-releases; when a project or release is quarantined, only the quarantine banner appears. The sidebar shows a release's provenance state when it is either full or flagged, linking to the security tab. Sidebar metadata has been reordered by usefulness and relabeled "PyPI data" or "Data verified by PyPI", replacing the old grouping by verification status.

The release files tab adds search and filtering for long file lists, shows each file's provenance state, and marks "late" files — those uploaded more than 14 days after the release's initial timestamp — with an orange warning icon. Those warnings only appear on releases from before July 2026, when a policy took effect that rejects files added after the 14-day window. The release history tab now also lists file counts, provenance state and release status — quarantined, yanked, archived or pre-release — for every release.

Backing and what comes next

The redesign implements recommendations from the OpenSSF Attestations Style Guide, was funded by the Open Source Security Foundation, and was built with design studio Kabu Creative. PyPI says the security tab will serve as a home for future attestation types and security notices, and it has published a case study in the style guide so other software repositories can reuse the patterns. User documentation has also been expanded with a package security guide covering how to assess source code, check provenance, verify package integrity, recognize common attacks and report issues.

Why it matters

As the Python ecosystem has grown, PyPI has drawn increasing attention from malicious actors, and supply-chain attacks on package registries tend to succeed when nobody questions where a file really came from. Attestations already existed, but as the PyPI blog itself concedes, provenance was an unfamiliar concept for many users and the old interface did little to explain it. Turning those cryptographic signals into visible states and actionable warnings makes verification part of the default view for anyone assessing a package, rather than an opt-in step. For maintainers, the practical takeaway is to adopt Trusted Publishing so future releases ship with attestations; for everyone else, checks that once required manual inspection now surface before the install command.