PEP 740 — "Index support for digital attestations" — was accepted in April 2024 and has been rolling through Warehouse implementation through the second half of 2024 and into 2025. It's a bigger deal than its quiet announcement suggested. For the first time, PyPI publishes cryptographic attestations alongside package files, signed by the identity that built them, verifiable without trusting the registry, and surfaced through the Simple API for consumers to check. This is the roadmap read as of March 2025, with a focus on what's actually deployed versus what's still coming.
What PEP 740 Actually Says
PEP 740, authored by William Woodruff and Dustin Ingram, specifies how PyPI exposes digital attestations attached to package files. The attestation format is Sigstore bundles — specifically, the bundle format defined by sigstore-python, wrapping in-toto statements that describe what was built, how it was built, and who built it. Each attestation is signed using a Sigstore-issued certificate, with the signing identity bound to an OIDC workload identity from the CI provider that produced the build.
The PEP specifies two endpoints the registry exposes: the attestation itself, and a verification endpoint that asserts the registry has verified the attestation against the project's trusted publisher configuration. Consumers can fetch either — the attestation itself for independent verification, or the registry's assertion for a faster trust-the-registry flow.
Critically, PEP 740 is descriptive rather than mandatory. It describes how attestations are exposed when they exist; it does not require every package to have one. This matters for adoption — the PEP could ship, be fully implemented, and still not meaningfully change the security story if nobody produces attestations.
What Has Actually Shipped
As of March 2025, here's what's real in production:
The Warehouse attestation endpoints are live. Packages published via Trusted Publishing from GitHub Actions automatically produce PEP 740 attestations as of the late-2024 rollout. The attestations are exposed through the Simple API and visible on package project pages. sigstore-python, the reference implementation, can verify PyPI attestations independently as of version 3.x (shipped late 2024).
What hasn't shipped as widely: mainstream installer verification. pip does not yet verify PEP 740 attestations as part of its install flow. The pip team has been discussing this through pull requests and discuss.python.org threads in Q1 2025, but the default pip install path remains unattested. For attestation verification today, consumers need explicit tooling — sigstore-python, pip-audit with newer versions, or custom verification scripts.
This means PEP 740 attestations are currently a publisher-side reality and a consumer-side opportunity. The supply is materializing; the demand is still being wired up.
Attestation Coverage
The most interesting question is how many PyPI packages actually have attestations now. Based on Warehouse statistics posted by the PyPI team in late 2024 and early 2025, attestation coverage at the file level was growing rapidly through 2024's second half but still a small fraction of total PyPI file volume — on the order of low single-digit percentages as of January 2025.
The reasons coverage is limited:
Only Trusted Publishing-based publishes produce attestations automatically. Packages published through traditional API tokens don't get attestations at all. Only GitHub Actions-based Trusted Publishing was initially supported; GitLab and Google Cloud support for attestations rolled out later. Many popular packages publish from custom build systems — wheel builds across multiple platforms using cibuildwheel on self-hosted infrastructure — where the attestation flow requires specific configuration that hasn't universally landed.
For the top 100 packages by download, attestation coverage is substantially higher than the overall average because these projects have been early Trusted Publishing adopters. Packages like cryptography, numpy, and requests have been producing attestations for most of their 2024 releases.
What Attestations Prove
It's worth being clear about what a PEP 740 attestation actually tells you and what it doesn't.
An attestation tells you: the package file was produced by a specific workflow (GitHub Actions workflow in repository X), running from a specific commit on a specific branch, at a specific time, signed by a specific workload identity. The registry verified the attestation's signing identity against the project's configured Trusted Publisher at ingestion.
An attestation does not tell you: that the source code in that commit is correct or safe; that the build process is reproducible; that the workflow wasn't subverted by a pull request from a malicious contributor; that the resulting artifact matches any particular SLSA level beyond what the build environment supported.
The attestation is a chain-of-custody claim, not a correctness claim. It's hugely valuable because the previous default was no chain of custody at all — a package file on PyPI was a bag of bits with no cryptographic tie to any specific producer. But it's not a vulnerability scan and not a code audit.
The Mandatory Attestation Question
The big unresolved question as of March 2025 is whether PyPI will eventually require attestations for certain classes of publishes. Several data points suggest this is coming, gradually, though not in 2025:
The PyPI team has publicly discussed making attestations mandatory for critical packages (top 1% by download), following the same tiered model used for 2FA enforcement in 2023. The OpenSSF SLSA work through 2024 has normalized attestations as the expected state for supply-chain-secure software. Large enterprise consumers — particularly those subject to US federal software-attestation requirements under EO 14028 and the associated CISA Secure Software Development Attestation — have been pushing for stronger provenance signals from upstream open-source.
My read: expect a Warehouse-side nudge in 2025 (warnings, visible "unattested" labels on package pages for critical projects that don't have attestations) and possible enforcement for critical packages in 2026. For non-critical packages, attestations will likely remain optional through the foreseeable horizon.
What Publishers Should Do
For a publisher operating in 2025, the practical roadmap:
Migrate to Trusted Publishing if you haven't already. This is the single change that unlocks attestations automatically. Verify that your Trusted Publishing workflow is using a current pypa/gh-action-pypi-publish version that produces attestations (the support landed in version 1.10.x and later). Inspect your published packages on PyPI — the attestation badge is visible on project pages — and confirm coverage is as you expect. For multi-platform wheel builds using cibuildwheel, update your workflow to the version that supports attestation emission across all platform builds.
If you're shipping from a non-GitHub CI provider, check the current support matrix. GitLab and Google Cloud support has been catching up, and the situation in March 2025 is meaningfully better than it was six months earlier.
What Consumers Should Do
For a consumer, the practical roadmap is shorter:
Start verifying attestations for your top-tier dependencies now, even if pip doesn't do it natively. Use sigstore-python or pip-audit to check attestation coverage across your lockfile and identify which dependencies provide attestations and which don't. Treat attestation coverage as an input to your supply-chain risk scoring — a critical dependency without an attestation isn't inherently bad, but it's a weaker signal than an attested one. Watch the pip attestation-verification PRs and be ready to enable the flag when it ships.
How Safeguard Helps
Safeguard verifies PEP 740 attestations for every PyPI package in your dependency graph and surfaces the coverage gap as part of your supply-chain risk view. For each dependency, Safeguard records whether an attestation exists, which workflow produced it, and whether the signing identity matches the project's configured Trusted Publisher. When an attested package ships an update, Safeguard verifies that the new release came from the same expected CI identity and flags anomalies — a workflow rename, a branch change, a new signer — as supply-chain events worth reviewing before the dependency lands in production.