Yes, for one failure mode. A short-lived publish token expires on its own, so a stolen one stops working quickly, while a long-lived token works until someone notices and revokes it. They do not stop a compromised build or malicious code committed by an authorized person.
Definition
A publish token is a credential that lets a build or a person upload a release to a package registry. Trusted publishing is the pattern where a CI platform proves its identity to the registry and receives a token for that one job. PyPI describes it as using OpenID Connect to exchange short-lived identity tokens, so publishers do not paste API tokens into their CI provider. Its documentation says such tokens expire about 15 minutes after creation, and that a traditional API token stays valid indefinitely until revoked.
What it improves
- Smaller theft window. A token lifted from a log or a developer laptop is already dead by the time it is used.
- Fewer secrets stored. Nothing long lived sits in CI settings waiting to leak.
- Better audit. Releases tie back to a specific workflow, not an anonymous token.
npm adds publish attestations, signed through Sigstore and recorded in a public transparency ledger, that link a package to its source and build instructions. The npm docs are direct that provenance does not guarantee the package has no malicious code. It gives you something to audit.
What it does not fix
| Risk | Covered by short-lived tokens? |
|---|---|
| Token stolen and used later | Yes |
| Attacker alters the workflow file and publishes through the trusted job | No |
| Malicious commit merged by a real maintainer | No |
| Typosquat of a legitimate package name | No |
| Account takeover with direct web login | Depends on account protections such as MFA |
What to ask when choosing a dependency
- Does the project publish through trusted publishing or an equivalent?
- Does the registry show provenance for recent releases?
- Do releases require review before the publishing workflow runs?
- Is there more than one person who can publish?
None of these is a guarantee. Together they make a hijack harder and easier to notice.
For your own packages
If you publish internally or externally, move to short-lived credentials where your registry supports it, protect the workflow that publishes as carefully as the code, and require review on changes to it.
Quick check
Is provenance the same as safety?
No. Provenance tells you where and how a package was built, not whether the code is benign.
Can I check how a package was published?
Where a registry shows provenance or attestations, yes. Look at the package page and the registry docs.
Where Safeguard fits
Safeguard offers dependency scanning and policies that can act on the dependencies you use. Publishing practice is something you evaluate in the packages you choose. A free scan lists them.
Sources
Last reviewed: 19 October 2026.
