PyPI Security tab now shows provenance and attestations for every release: what the new warnings mean

PyPI has finished redesigning its project pages so that where a release came from is visible at a glance. A new Security tab shows each release's provenance state and per-file attestations, and warning banners appear when a project's publishing setup changes in ways that can signal a compromised pipeline or account. The change went live on 6 November 2026, according to the PyPI blog, and has already started an argument on the Python forum about whether it quietly pressures projects into using Trusted Publishing.

Key points

• PyPI project pages now have a Security tab listing each release's provenance state and per-file attestations, per the PyPI blog post dated 6 November 2026.
• A release has full provenance when every file has an attestation, no provenance when none does, and gets a warning when files are missing attestations, come from different pipelines, or the publishing identity changes or disappears.
• Two attestation types are supported: PyPI Publish (the file came from a Trusted Publisher) and SLSA Build Provenance (it links to the source commit, build platform and build instructions).
• PyPI says "no provenance" does not mean a release is malicious. The page text reads: "No provenance does not necessarily indicate that a release or release file is malicious."
• The work was funded by the Open Source Security Foundation (OpenSSF) and follows its Attestations Style Guide.

What to do

If you maintain a Python package: publish through Trusted Publishing from a CI identity such as GitHub Actions. If you use the pypa/gh-action-pypi-publish action, PyPI's documentation says attestations are generated and uploaded automatically by default, with no extra step. Publishing manually? The docs describe pypi-attestations sign dist/* (or actions/attest with the PyPI publish predicate type) followed by twine upload --attestations. PyPI rejects attestations from identities other than Trusted Publishers.

If you already publish with attestations: keep every release consistent. Upload all files for a release from the same workflow. Moving to a different repository or workflow, or dropping attestations, now shows a visible warning to anyone who looks at your project page.

If you consume packages: open a project's Security tab before you add a dependency or when a new release looks odd. Read it as one signal among others. Pip does not verify attestations itself; the PyPI docs name the third-party pip-plugin-pep740 for that, and list native support in pip and uv as proposed but not in active development. You can also fetch attestations from the PyPI Integrity API.

What happened

PyPI's blog post says the page updates are now complete. The Security tab shows each release's provenance state and its per-file attestations. It is meant as a home for future attestation types and security notices as well.

Status banners now sit at the top of the page: yanked, archived and pre-release, plus provenance warnings. A quarantine banner replaces all the others. When a release has full provenance or warnings, its state appears in the sidebar and links to the Security tab. The sidebar metadata is now ordered by usefulness and labelled "PyPI data" or "Data verified by PyPI", where it used to be grouped by verification status.

The Release files tab gained search and filters and shows each file's provenance state. The Release history tab shows each release's file count, provenance state and status (quarantined, yanked, archived or pre-release). Files uploaded more than 14 days after a release's first upload get an orange warning icon, but only on releases before July 2026, when PyPI began rejecting new files after 14 days.

Help Net Security, reporting on 9 November, describes the same changes and adds that the Security tab is where users can check provenance details or follow a link to the transparency log.

Background

Digital attestations arrived on PyPI in 2024. They follow PEP 740 and are recorded as Sigstore transparency log entries, a permanent public record. PyPI announced the planned interface changes in July 2026. The blog post says the work was funded by the OpenSSF and implemented by Kabu Creative, based on the OpenSSF Attestations Style Guide, and that a case study on the design patterns and warnings is published in that guide.

The reason for putting this in front of ordinary users is the steady run of package-registry compromises, including our report on stolen GitHub accounts probing tens of thousands of repositories. An attestation does not prove code is safe. The PyPI docs say it shows where a file came from, and that trusting it means implicitly trusting the issuing organisation. What it does give reviewers is a way to notice when a release suddenly comes from somewhere new.

How it works

PyPI checks whether each file in a release has an attestation and reports one of these states, per the PyPI blog:

• Full provenance: 100% of files have attestations.
• No provenance: no file has an attestation. This is common for older releases and for projects without Trusted Publishing.

A project in a neutral state shows no alarm. Four warnings are reserved for changes:

1. Incomplete: some files have attestations and others do not. The blog's example is a release where 2 of 5 files were uploaded without provenance metadata.
2. Inconsistent: files in the same release come from different build systems or repositories.
3. Change of provenance: the release comes from a different repository or workflow than the previous release. That may be a legitimate migration or a sign of a compromised pipeline or account.
4. Loss of provenance: a project that previously published with attestations now uploads files without them.

According to PyPI's docs, change and loss warnings only appear when the release differs from one made in the preceding 14 days. William Woodruff, who said he worked on the original Trusted Publishing and attestation designs, said on the forum that the "lost provenance" flag clears 14 days after the last attested release if nothing else happens. He wrote that in a personal capacity and said he was not directly involved in the recent interface work.

One wording difference is worth knowing about: the PyPI blog defines full provenance as every file having an attestation, while the PyPI documentation page describes a release as having provenance when at least one file does, and Help Net Security says a release has full provenance when every file has at least one attestation. The blog's definition is the one the new tab displays.

What it means

For maintainers: the cost of staying quiet rose a little. A release with no attestations looks neutral, but one that drops attestations or arrives from a new workflow gets a banner. Anyone planning a CI migration should expect questions and may want to say so in the release notes.

For users and security teams: there is now a place on the page to look, and it is machine-readable through the Integrity API. But many older releases have no provenance, so the tab will not separate good from bad for those packages.

For projects on other infrastructure: a Python forum thread posted on 7 November by Ricardo Newbery argues the design creates a two-tier system, because projects that publish from infrastructure PyPI does not yet support as a Trusted Publisher, such as Codeberg, cannot easily earn the positive signal. He also said a "No provenance" label might alarm users even in a neutral colour.

Woodruff replied that PyPI wants more Trusted Publisher providers but is limited by maintainer review time and security concerns. He said Forgejo-based forges such as Codeberg currently store identity-provider private keys on disk, which he considers an unacceptable risk for now, and that pip and uv will not require attestations. He also said email-based attestations have been proposed to break the link to CI providers. Other participants raised smaller points: Hugo van Kemenade described Pillow's "Incomplete provenance" warning after some wheels were uploaded manually, and others discussed icon and wording choices.

What we don't know yet

• How many projects or releases have attestations today. Neither the PyPI post nor Help Net Security gives adoption figures.
• Whether PyPI will change the "No provenance" label or its icon in response to the forum thread. We saw no official PyPI response beyond Woodruff's personal reply.
• When native verification will arrive in pip or uv. The docs call it proposed but not in active development.
• How quickly a legitimate change, such as a repository move, can be cleared from a warning. The forum asked for a safe way, and the answer we found is the 14-day window.

What to watch next

• Adoption numbers for attestations, and whether the share of releases with full provenance climbs.
• New Trusted Publisher providers and the email-based attestation proposal.
• Whether pip, uv or other installers start surfacing the same warnings at install time.

Sources

• PyPI blog: project page UI updates complete (primary source)
• PyPI docs: provenance and attestations
• PyPI docs: producing attestations
• Help Net Security: PyPI makes release attestations easier to find with new security tab
• Python Discourse: PyPI's new security indicators and unequal access to Trusted Publishing