Commit access and publish access are separate. The people who merge code, the accounts that hold registry tokens, and the CI workflows allowed to publish can all differ. For risk, the publishing set matters most, because whoever controls it controls what you install. Trusted publishing narrows that set to a workflow.
Three sets, not one
When you read a repository, you see committers and reviewers. The registry has its own list of accounts that can publish a package, and those accounts may hold long-lived tokens stored in CI secrets or on laptops. A third path, the build workflow itself, may publish on behalf of the project.
| Set | Where you can see it | Risk if compromised |
|---|---|---|
| Committers and reviewers | Repository | A bad change could merge, subject to review |
| Registry publishers | Registry package page | A release could ship with no code change in the repository |
| Publishing workflow | Workflow file, attestations | A bad workflow change could ship a release |
The OpenSSF Concise Guide asks you to verify more than one maintainer, ideally from different organizations. That is the first set. The second set rarely appears in assessments, and it is where a stolen token does its damage: a release can reach the registry without a matching commit.
How trusted publishing changes this
npm documents trusted publishing as a way to publish from CI/CD workflows using OpenID Connect, removing the need for long-lived npm tokens. When a trusted publisher is configured, npm accepts publishes from the specific workflow authorized. The docs list supported providers including GitHub Actions on GitHub-hosted runners and GitLab CI/CD, and note requirements on the npm CLI and Node versions. PyPI and RubyGems offer similar features.
The docs describe each publish as using short-lived, workflow-specific tokens that cannot be extracted or reused. Note that npm says it accepts the authorized workflow in addition to traditional authentication such as tokens and manual publishes. So turning the feature on does not by itself close those older paths.
What to ask as a consumer
- Does the package publish with attestations that name a workflow? That suggests the publishing path is a known build.
- Has the registry maintainer list changed lately? A change near a release is worth a look.
- Does the project document how it protects publish access, for example two factor authentication and restricted tokens?
- For critical packages, can you wait a few days before adopting a new version, so a bad release is more likely to be caught?
What to do on your own packages
If you publish packages, count how many accounts and tokens can publish today. Remove ones you do not need, move to a trusted publisher setup where your registry supports it, and turn off token-based publishing once the workflow path works.
Try it yourself
Click through it at your own pace, or open it full screen. It lists the components that publishing paths ultimately feed into your builds.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning and policies and gates, so changes to the components you consume are visible. A free scan is at gold.safeguard.sh/scan.
Quick check
Does trusted publishing make a package safe?
No. It protects the publishing path from stolen tokens. The source and the workflow itself still need to be sound.
Can I see who can publish a package?
Registries usually show a maintainers list on the package page, though what is visible varies by ecosystem.
Sources
- npm Docs: Trusted publishing for npm packages
- OpenSSF Concise Guide for Evaluating Open Source Software
Last reviewed: 19 October 2026.
