PyPI Security Tab: How to Check a Python Package's Origin

The Python Package Index just made one of its best security features far easier to see. PyPI's redesigned project pages, completed and announced on November 6, 2026, add a dedicated Security tab that tells you whether a release's files can be traced back to where they were built and published. For anyone installing packages into AI pipelines, data tooling or production services, that is a practical upgrade to everyday software supply chain hygiene.

• The new Security tab shows a release's provenance state and the attestations attached to each file
• A release has full provenance when every file has at least one attestation; none means no provenance
• PyPI flags four warning cases: incomplete, inconsistent, change of provenance and loss of provenance
• The work follows the OpenSSF Attestations Style Guide and was built with design partner Kabu Creative

What Does the PyPI Security Tab Show?

Digital attestations arrived on PyPI in 2024 as a verifiable record of where a release file came from, but the old interface did little to explain them. The new tab fixes that. PyPI supports two attestation types. A PyPI Publish attestation confirms the file was uploaded by a Trusted Publisher, while a SLSA Build Provenance attestation ties the file to its source commit, build platform and build instructions. You can read the details on the page or follow a link to the public transparency log.

As Help Net Security notes, PyPI design contributor Nicole Harris stresses that a release with no provenance is not necessarily malicious. It is common for older releases and for projects that have not yet set up Trusted Publishing. It simply means the origin cannot be cryptographically verified, so you lean on other signals such as maintainer history, release patterns and repository activity.

How Do Provenance Warnings Help Developers?

The warnings are where this gets genuinely useful for defenders. PyPI alerts you when only some files in a release are attested, when files in one release come from different repositories or build systems, when a release comes from a different repository or workflow than the previous version, and when a project that used to provide attestations stops doing so.

Often there is an innocent explanation, such as an organization renaming itself or moving a repository. But the same signals can point to a compromised build pipeline or an account takeover, which is exactly the kind of quiet change that is hard to spot by eye. These warnings now appear at the top of the redesigned project page alongside notices for yanked releases, archived projects and pre-releases.

Better Tools for Software Supply Chain Security

The redesign also improves the Release Files and Release History tabs. You can search and filter downloads, see each file's provenance status, and compare versions side by side. For releases that predate PyPI's July 2026 policy change, files uploaded more than 14 days after the initial release are flagged; since that change, PyPI rejects late uploads entirely.

If you maintain a package, the best next step is to configure Trusted Publishing so your releases earn full provenance automatically. If you consume packages, make the Security tab part of your review before adding a new dependency. It pairs nicely with tools like Chainloop's open-source supply chain evidence platform, and you can find more defensive guides in our AI security coverage.

Sources: PyPI Blog — November 6, 2026; Help Net Security — November 9, 2026.