PyPI Trusted Publishing lets a CI or build system publish packages to PyPI using short-lived, trusted identity instead of a long-lived password or API token. That reduces secret theft risk and limits credential reuse. Teams should still restrict who can trigger releases, verify workflow permissions, and monitor for unexpected package uploads or ownership changes.
How Trusted Publishing Changes the PyPI Release Trust Model
trusted publishing replaces a reusable PyPI password or API token with short-lived identity assertions from the build environment. That means the release action is tied to a specific workflow run and repository context, rather than to a secret that can be copied, reused, or quietly retained after compromise. The practical shift is from “hold a credential” to “prove release authority at publish time.”
That matters because publishing becomes an authorization decision, not a static credential possession test. If the workflow identity is valid and the repository is allowed to publish, PyPI accepts the release without exposing a long-lived secret that can be exfiltrated from CI logs, environment variables, or developer machines.
For release engineering teams, the important detail is that Trusted Publishing narrows the blast radius of a compromised pipeline account. It does not make every workflow safe, but it does remove one of the easiest persistence paths for package attackers: stolen publish tokens that can be reused later from anywhere.
What Has to Be True for a Publish to Succeed
Trusted Publishing works only when the build system and PyPI can establish a trusted relationship for that specific release event. In practice, that means the release workflow must be the one expected to publish, the triggering conditions must be constrained, and the workflow permissions must be limited to what the release job actually needs. The trust boundary is the release pipeline, not the human developer’s laptop.
That also means release discipline still matters. A broad workflow trigger, an over-permissive repository role, or an unreviewed change to the publish job can turn a strong authentication model into a weak one. Trusted Publishing reduces secret handling risk, but it does not replace change control around the release path itself.
When teams use this model well, they also make package ownership and workflow ownership align. The people who can merge release-related changes, trigger a publish, and modify repository settings should be a deliberately small set, because the security of the system depends on those controls staying consistent.
For a practical reference point on the broader release-path controls around CI identity, token minimisation, and keyless publishing, see the CI/CD Pipeline Identity Security Guide.
Release pipelines are also part of a wider software supply chain risk model, which is why the Open Source Security Guide is relevant to teams deciding how to harden package publication and provenance.
Why This Reduces Secret Theft and Package Abuse
The main security gain is elimination of the long-lived publish secret. If an attacker steals a PyPI password or API token, they may be able to publish malicious releases long after the original compromise. Trusted Publishing removes that durable credential from the normal release path, which sharply reduces reuse and makes stolen material less valuable.
The model is especially useful in environments where attackers target CI systems, maintainer accounts, or build logs. A short-lived identity assertion is harder to replay than a standing secret, so a compromise that once enabled indefinite package publishing is reduced to a narrower, time-bound opportunity. That does not stop a malicious build from shipping bad code, but it does make post-compromise persistence much harder.
It also helps with package ecosystem abuse patterns that depend on secret sprawl. If publish credentials are not stored in the repository, runner, or developer workstation, there is less material for secret scanning failures, less exposure from leaked environment variables, and less chance that a token will be reused across projects or environments.
For a real-world example of why this matters, Ultralytics PyPI compromise 2024 shows how a CI weakness plus a leftover token can still be enough to ship malicious releases. A release model that removes the standing token materially changes that failure mode.
The same lesson appears in Shai-Hulud npm worm first wave 2025, where stolen publishing tokens were a key enabler of large-scale package abuse.
Another useful comparison is the PyPI secrets exposure 2023 research, which illustrates how exposed secrets can persist in the ecosystem even after a package changes state.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Trusted Publishing replaces long-lived publish secrets with short-lived identity assertions. |
| NHI-07 — Long-Lived Secrets | The answer centers on avoiding reusable PyPI passwords or tokens in CI. | |
| NHI-05 — Overprivileged NHI | Release workflows must have only the permissions needed to publish packages. | |
| Recommendation — Remove standing publish secrets and prefer short-lived release authentication. Eliminate long-lived publishing credentials from the release path. Scope publishing identities to the minimum release permissions required. | ||
| CIS Controls v8 | CIS-5 — Account Management | Publishing access depends on tightly governed accounts, roles, and release triggers. |
| Recommendation — Limit who can trigger releases and manage publish-capable accounts. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service and Workload) | CI systems publish via trusted machine identity rather than shared secrets. |
| Recommendation — Use workload authentication for release automation instead of reusable tokens. | ||
Practitioner Guidance
What to prioritise: Treat release permissions as the primary control plane. Restrict who can merge release changes, who can trigger the workflow, and who can change repository settings that affect publishing. If those controls are loose, Trusted Publishing only removes one weak point while leaving the release path itself exposed.
What to verify: Confirm that the workflow used for publishing is the exact workflow you intend to trust, that the publish step is isolated from unrelated build logic, and that no fallback secret-based publishing path still exists. Also verify that package ownership changes and unexpected uploads generate visible review signals.
Common mistake: Teams often stop after “we no longer store a PyPI token.” That is incomplete. The real question is whether the release pipeline can still be abused to publish an unauthorised package, because the trust shift only works when workflow permissions and repository governance are equally tight.
Practitioner takeaway: Trusted Publishing is strongest when it removes standing secrets and when the release workflow is itself tightly governed, because the security outcome depends on both short-lived identity and release-path control.
Related resources from NHI Mgmt Group
- Guide: Malicious Package and Dependency Confusion Guide
- PyPI Trusted Publishing
- What do security teams get wrong about package provenance and trusted publishing?
- Who is accountable when a release workflow publishes malicious code through trusted publishing?
- Why do trusted-publisher workflows create a different risk profile than ordinary package publishing in modern CI environments?