For an adopter, a package that uses npm trusted publishing is a positive process signal: releases come from a named CI workflow using short-lived credentials instead of a long-lived write token that can leak. It narrows one attack path. It does not prove the code, the workflow, or the maintainers are safe.
What trusted publishing is
According to the npm documentation, trusted publishing lets maintainers publish from CI/CD workflows using OpenID Connect instead of long-lived npm tokens, following the OpenSSF trusted publishers standard. The maintainer sets up a trust relationship between the package and a specific workflow on npmjs.com. Each publish then uses short-lived, signed credentials tied to that workflow.
The supported providers are GitHub Actions, GitLab.com shared runners and CircleCI cloud, all on cloud-hosted runners. Self-hosted runners are not supported. Up to 10 trusted publishers can be set per package.
What it removes
The npm docs say it removes the risks of long-lived write tokens, which can be compromised, leaked into logs, or need manual rotation. A stolen token from a developer laptop or a CI log no longer lets an attacker publish, if token publishing has been restricted. npm recommends restricting traditional token publishing once trusted publishers work, so a project that did both steps is stronger than one that only added the new path.
Provenance attestations are generated automatically for GitHub Actions and GitLab publishes from public repositories of public packages. CircleCI does not generate them.
What it does not remove
| Still possible | Why |
|---|---|
| Malicious change merged into the repository | The workflow faithfully publishes whatever is in it |
| Compromised workflow | If an attacker controls the trusted workflow, they control the publish |
| Vulnerable code | Process says nothing about code quality |
| Lost maintainer access | Does not address continuity |
Our post on the AsyncAPI pipeline hijack discusses why the workflow itself needs scrutiny. Review it as described in reviewing GitHub Actions workflows before adopting.
How to check as a consumer
- Look at the package's registry page for provenance information.
- Run
npm audit signaturesin your project to see verified attestations. - Open the linked workflow. Is it small and readable, with read-only permissions and pinned actions?
- Look for a release pattern: do versions appear after pull request merges, or at odd times with no matching commits?
- Ask the maintainer, politely, whether token publishing is disabled.
Note that npm warns attestation formats may change over time, so keep your CLI current to keep verifying.
Score it
Give a point for trusted publishing plus provenance, and a second for restricted tokens and a reviewed workflow. Add the result to your adoption record.
Safeguard can help here. Its SBOM and dependency scanning, reachability analysis and policy gates cover the checks that should repeat after adoption, and the free scan at gold.safeguard.sh/scan shows what a project already depends on.
Quick check
Does trusted publishing mean the package is safe?
No. It secures how a release is published, not what is in the repository.
What if the project uses a self-hosted runner?
npm trusted publishing does not support self-hosted runners, so such a project must use another publish method. Ask how it protects its credentials.
Sources
Last reviewed: 19 October 2026.
