What are the key PyPI Trusted Publishing best practices?

How Trusted Publishing Changes the Release Security Model

trusted publishing works best when publication is treated as a narrowly scoped, automated trust path rather than a reusable credential problem. It shifts the control point from shared secrets to the release workflow itself, which means the main security task becomes constraining who or what can trigger publication, what artefacts are eligible, and what project settings can alter that trust path.

That is why the strongest mental model is not “protect the token,” but “protect the publishing boundary.” In practice, the boundary should be anchored to the expected repository, workflow, environment and ownership model. A release process that allows broader reuse, manual overrides, or loosely controlled project settings reintroduces the same risk Trusted Publishing is meant to remove.

Trusted Publishing also changes what you need to review before a release. The check is no longer only whether a secret exists, but whether the artefact, metadata and ownership state still match the intended source of truth. That includes release tags, dependency metadata, maintainer changes and any automation path that could silently redirect publication to a different actor or workflow.

Where PyPI Releases Still Go Wrong

The most common failure mode is assuming that removing upload secrets automatically solves release integrity. It does not, because an attacker who can alter workflow permissions, repository settings, or maintainer ownership may still be able to publish malicious or unexpected artefacts through the trusted path. The control is only as narrow as the surrounding project governance.

A second failure mode is over-broad trust in the automated workflow itself. If the repository can be tampered with, or if release jobs can be made to run from untrusted branches, tags or contributors, Trusted Publishing may still publish the wrong package content. The same is true when release settings are changed without review, because the publication path is then trusted on the basis of configuration drift rather than deliberate approval.

For broader package-supply-chain context, NHIMG’s Malicious Package and Dependency Confusion Guide covers the package abuse patterns that make release trust boundaries worth tightening in the first place. Release compromise often starts before publication, through metadata manipulation, namespace confusion or dependency abuse that makes a package appear legitimate when it is not.

Trusted Publishing is also vulnerable when teams treat ownership and publication rights as static. If maintainers change, automation accounts are reused, or repository permissions expand over time, the original trust decision may no longer match the current operating reality. That is why release governance must be reviewed as part of routine project administration, not only during a security incident.

What a Safe PyPI Publishing Process Looks Like

A safe process starts with removing manually managed upload secrets wherever Trusted Publishing is available, then verifying that the intended automated workflow is the only path that can publish to the project. That includes checking repository bindings, branch or tag conditions, and any environment approvals that gate release execution. The goal is to make publication predictable, attributable and hard to reroute.

From a control perspective, the release job should be as narrow as possible. The workflow should build and publish only what was approved, from the expected source, and with minimal surrounding permissions. If the same workflow can edit settings, access unrelated secrets, or write to more than one project, the publishing boundary is too broad.

Release review should also include artefact integrity and ownership checks. Before a trusted release goes out, confirm the package contents, metadata, versioning and maintainer state all match expectations. Where ownership or repository administration has changed, treat that as a security-relevant event rather than an administrative note.

For the automation side of the release path, NHIMG’s CI/CD Pipeline Identity Security Guide is the most direct companion for understanding why keyless federation, restricted permissions and pinned workflows matter to trusted publication. If your pipeline identities are too broad, the publish path becomes a high-value access path instead of a tightly controlled release mechanism.

When teams need a concrete incident-informed perspective on what goes wrong, NHIMG’s Ultralytics PyPI compromise 2024 shows how a workflow injection path and leftover credentials can combine to produce a malicious release. It is a good reminder that Trusted Publishing reduces secret risk, but does not remove the need to secure the build and release workflow itself.

Practitioner Guidance

What to verify: Confirm the publishing path is actually keyless in practice, not just documented that way. Check the repository binding, workflow source, and release conditions, then verify that no alternate upload path or legacy token can still publish to the project.

Decision rule: If the project settings or workflow permissions can be changed by a broader set of people than the package maintainers who should control releases, treat that as a trust-boundary problem, not a convenience feature. Narrow the path first, then decide whether additional review gates are needed.

What practitioners underestimate: The dangerous change is often not the release artefact itself, but the project setting, ownership update or automation tweak that silently expands who can publish. Trusted Publishing works best when those adjacent controls are reviewed with the same discipline as the release job.

Practitioner takeaway: Trusted Publishing is most effective when it removes secrets and constrains publication to one provable workflow, but the real security outcome depends on keeping repository trust, ownership and release permissions just as narrow.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• What is the difference between role-based access and API key governance for NHI security?
• When does a short-lived API key still create material risk?
• What are the key privileged account best practices?