A PyPI attestation is a signed statement, defined by PEP 740, that ties a specific release file to the identity that produced it. A publish attestation shows the file went out through a trusted publisher. It proves where a file came from. It does not prove the code is safe.
What an attestation contains
PyPI's documentation says attestations use the in-toto Attestation Framework. Each one binds a release file, either an sdist or a wheel, to a cryptographic digest of its contents. Because of that binding, a user can confirm that a particular package was attested to by a particular identity.
Two kinds are described:
- Publish attestations, which give publicly verifiable proof that a package was published through a Trusted Publisher.
- SLSA Provenance attestations, which describe the package's original source location.
Who can sign
PyPI lists GitHub Actions, GitLab CI/CD and Google Cloud as accepted signing identities, along with ActiveState. Signing is limited to those trusted publisher identities. Each file may carry at most two attestations, one per predicate type. An upload with more than two, or with a repeated predicate, is rejected.
PyPI's attestations page does not give verification commands or the steps for generating attestations in a workflow. Check PyPI's current guides and your publish action's documentation before you rely on a specific setup.
What a good attestation tells you
- The file you hold matches the one the signer attested to.
- The signer was a specific repository and workflow, not a person with a stolen token.
- For provenance, where the source was supposed to live.
That is useful for catching a file swapped on a mirror or uploaded from a laptop.
What it cannot tell you
An attested malicious build is still malicious. If an attacker controls the workflow, they can publish with a perfectly valid attestation. The same limit applies elsewhere, which we covered in signature, provenance and SBOM attestation explained. Treat attestations as one signal beside maintainer history, release age, and dependency review.
For consumers, the practical rule is to prefer attested releases when you can verify them, and never skip review because a check passed. For maintainers, publishing through a trusted publisher is the way to get attestations in the first place, so start with the setup steps.
Safeguard's SBOM and dependency scanning shows what is in your build, which attestations alone do not.
Quick check
Does an attestation mean a package is safe?
No. It shows who produced the file and, for provenance, where the source lived. It says nothing about whether the code is benign.
How many attestations can one file have?
At most two, one per predicate type. Extra or repeated ones cause the upload to be rejected.
Sources
Last reviewed: 19 October 2026.
