A PyPI attestation is a cryptographic statement that binds a specific release file to a digest and to an identity, such as a GitHub Actions workflow. It proves where and how a file was published. It does not prove the code is free of vulnerabilities or that the maintainer's intent was benign.
What the documentation says
PyPI's documentation describes digital attestations as an implementation of PEP 740. They let maintainers and third parties, such as the index or auditors, sign for uploaded packages. The signatures bind each release distribution, such as an individual sdist or wheel, to a strong cryptographic digest of its contents. Both PyPI and downstream users can then verify that a particular package was attested to by a particular identity.
Two forms are named. Publish attestations give publicly verifiable proof that a package was published through a specific Trusted Publisher. More general SLSA Provenance attests to a package's original source location. PyPI uses the in-toto Attestation Framework for what it accepts.
Trusted Publishing in one paragraph
PyPI uses the term Trusted Publishing for OpenID Connect based exchange of short-lived identity tokens between a trusted third-party service and PyPI. It removes the need for manually generated API tokens when publishing from automation. A long lived token that leaks from a lab laptop is exactly the failure this avoids.
What it proves and does not prove
| Claim | Proven by an attestation? |
|---|---|
| This file came from this workflow | Yes, that is its purpose |
| The file has not changed since attestation | Yes, bound to a digest |
| The source repository is the one named | Supported by provenance forms |
| The code has no vulnerabilities | No |
| The workflow owner is trustworthy | No, you still decide that |
Steps for a research package maintainer
- Publish through a trusted publisher instead of a stored token. See PyPI trusted publishing adoption guide.
- Separate build and publish jobs. See why separate build and publish jobs for PyPI releases.
- Produce attestations using the method in PyPI's producing attestations page.
- Mention in your README how users can check them.
Steps for a consumer
- Check whether the packages you depend on publish attestations. Where PyPI's consuming page describes a verification step, use it.
- Treat a missing attestation as a gap in evidence, not as proof of a problem.
- Still pin exact versions and hashes. See can pip require hashes protect an ML environment.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a gate decides whether a change may proceed, a pattern you can apply to dependency updates.
Quick check
Does an attestation mean a package is safe to install?
No. It shows origin and integrity of the file. Safety still depends on the code and dependencies, so scan and review.
Do I need an attestation to publish to PyPI?
No. They are an option that PyPI documents. Maintainers choose whether to produce them.
Safeguard's dependency scanning and policies can check packages in your projects, and a free scan is available.
Sources
Last reviewed: 19 October 2026.
