Binding npm and PyPI publishing identity to approved release artifacts

What it is

Status as of 25 October 2026. Trusted publishing exchanges CI identity for temporary registry credentials instead of storing a permanent publishing token. Re-check the registries' supported providers, runner restrictions, and configuration requirements before changing a release workflow. The cited documentation is a living reference retrieved for this review, not a dated incident advisory.

For npm, the documented prerequisites are npm CLI 11.5.1 or later and Node 22.14.0 or later. This article concentrates on GitHub Actions workflows that publish npm packages or Python distributions to PyPI.

Why it matters

PyPI's security model explicitly leaves workflow integrity with the publisher. Temporary credentials remain sensitive, and a compromised authorized workflow can obtain them. Removing stored tokens reduces credential exposure without making dependency execution safe.

npm's provenance documentation distinguishes a verifiable connection to source and build instructions from a guarantee that code is harmless. The operational inference is straightforward: an authorized pipeline can attest a malicious artifact. Approval must evaluate the release inputs and output, as well as the identity signing it.

How to apply

• Register the intended owner, repository, and publishing workflow precisely. For npm's GitHub configuration, enter the workflow filename and bind the optional environment name to the protected publishing environment. Check the configured identity against the actual job before removing the previous authentication route.
• Follow PyPI's separation pattern: a build job creates distributions; a small publishing job retrieves and uploads them. Give permissions: {id-token: write} only to the job that needs OIDC. Keep dependency installation, tests, and untrusted changes outside that job's authority.
• Configure environment reviewers, prevent self-approval, restrict release branches or tags, and disable administrator bypass where supported. Verify feature availability for the repository and plan. GitHub's default permits administrators to bypass environment protection; a named environment alone is insufficient.
• Make approval specific: record the source revision, build run, and artifact digest in the release record, then publish those reviewed bytes. Check attestation identity and source information against that record. Investigate mismatches instead of accepting a provenance badge as the release decision.
• Review workflow code and third-party actions. Grant repository tokens minimal permissions and pin actions to reviewed full commit identifiers. Never print credentials or dump the environment for debugging. GitHub warns that automatic log masking can fail, including when values are transformed; inspect failure-path logging as well as successful runs.
• After migration, remove unused publishing tokens and audit trusted-publisher registrations. PyPI registrations belong to projects and survive removal of the person who created them. Include them explicitly in maintainer offboarding.

Pitfalls

An approval gate cannot compensate for a compromised approver account or unreviewed changes to the gate itself. A reusable build cache and a persistent runner need their own trust assessment. Record rejected identity or artifact checks as release failures; silently falling back to a stored write token undermines the intended control.