PyPI Trusted Publishing is a method for publishing Python packages without using long-lived password or API tokens. It uses federated identity from the build system to prove the publisher’s identity at release time. This reduces secret theft risk, but teams still need to secure build pipelines, review package ownership, and monitor publication events.
What PyPI Trusted Publishing Changes
PyPI trusted publishing replaces long-lived password or API token publishing flows with federated identity from the build system, so package releases can be authenticated at release time without storing reusable publishing secrets.
This matters because the release path itself becomes part of the trust boundary, not just the package index. When publication is tied to the build environment, the main security question shifts from “can someone steal a static token?” to “can they impersonate or subvert the trusted build workflow?”
Why It Reduces Secret Exposure
The strongest security benefit is the removal of durable credentials from developer laptops, CI variables, and release automation. That lowers the chance that a stolen token can be reused later, and it makes secret scanning, rotation, and revocation less central than they are with classic upload tokens.
Trusted publishing does not eliminate credential abuse risk entirely. It changes the trust model so the build system’s identity proof, repository binding, and release-time assertions do more of the work. That means the integrity of the pipeline and the configured trust relationship become more important than the secrecy of a single token.
For a practical control lens on this shift, NHIMG’s CI/CD Pipeline Identity Security Guide covers the same keyless federation pattern in release automation.
Where Release Trust Can Still Fail
Trusted publishing only helps if the build workflow is itself trustworthy. A compromised runner, poisoned workflow file, abused pull request path, or over-broad repository permission can still let an attacker publish malicious artifacts under a legitimate package identity.
That is why package ownership, branch protection, workflow review, and release approvals remain relevant even when tokens are removed. The signing or assertion step may be keyless, but the environment that produces the assertion can still be manipulated.
Readers looking at real-world package compromise patterns should also compare this model with NHIMG’s Malicious Package and Dependency Confusion Guide, which places trusted publishing in the broader package-security context.
How Teams Should Think About Exposure and Monitoring
Organisations adopting trusted publishing should inventory every package release path, confirm which build systems are allowed to assert publisher identity, and verify that package ownership matches the actual maintainers. They should also monitor publication events so unexpected releases are visible quickly.
Post-release review still matters. If a build system is compromised, a bad release can be legitimate from the registry’s point of view, so teams need logs, provenance records, and a way to inspect whether a published artifact came from the expected workflow and source state.
The risk becomes clearer when you view it alongside incident-driven supply-chain analysis. NHIMG’s Ultralytics PyPI compromise 2024 and Shai-Hulud npm worm first wave 2025 both show how publishing paths and CI trust can be abused when release controls are weak.
Risk and Threat Considerations
Trusted publishing reduces the value of stolen static publishing secrets, but it increases the importance of the build pipeline as a trust anchor. If an attacker can compromise the workflow, runner, or source-control permissions, they may still publish a malicious package that appears to come from the legitimate maintainer.
Failure mechanism: The attacker subverts the trusted build context, then uses that trusted context to mint a valid publication event or release assertion.
Impact: A malicious package can be distributed through the official registry, creating downstream compromise, dependency contamination, and potential credential theft from users who install or update it.
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, OWASP SAMM and SLSA 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 exists to remove long-lived publishing secrets from release workflows. |
| NHI-05 — Overprivileged NHI | Package publishing identities and build workflows can be granted excess release power. | |
| Recommendation — Eliminate reusable upload tokens and credentials from package publication flows. Constrain publishing identities to the minimum release permissions needed. | ||
| CIS Controls v8 | CIS-5 — Account Management | Package ownership and release authority depend on managing who can publish and approve releases. |
| Recommendation — Review and revoke publication access paths when ownership or workflow roles change. | ||
| OWASP SAMM | Software Assurance Maturity Model | Release workflow governance and build integrity are part of secure software delivery maturity. |
| Recommendation — Embed release identity, provenance, and approval checks into the delivery process. | ||
| SLSA | Supply-chain Levels for Software Artifacts | Trusted publishing depends on build provenance and artifact integrity in software supply chains. |
| Recommendation — Require provenance evidence for release artifacts and verify the build source. | ||
Practitioner Guidance
Why practitioners should care: Trusted publishing is most effective when it removes reusable secrets and narrows the release surface, but it also makes build integrity and ownership discipline the primary controls to get right. Treat the release workflow as production-critical security infrastructure, not just a developer convenience.
Practitioner takeaway: Use trusted publishing to eliminate long-lived upload credentials, then harden the pipeline and review publication telemetry with the same care you would apply to any privileged release path.
Related resources from NHI Mgmt Group
- 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?
- How should security teams implement Trusted Publishing for npm packages in CI pipelines?