GitHub Actions

npm Trusted Publishing: Safer GitHub Actions Releases

By CI Tripwire Editorial · Published 2026-06-08 · 7 min read

npm trusted publishing can remove long-lived npm publish tokens from release workflows, but it does not make the workflow itself harmless.

Key takeaways for npm trusted publishing

  • npm Docs says trusted publishing uses OIDC so GitHub Actions and other supported CI/CD providers can publish without long-lived npm tokens. [1]
  • npm Docs says GitHub Actions trusted publishing requires npm CLI 11.5.1 or later and Node.js 22.14.0 or higher. [1]
  • npm Docs says trusted publishing from GitHub Actions or GitLab CI/CD automatically generates and publishes provenance attestations for the package. [1]
  • npm Docs says trusted publishing currently supports only cloud-hosted runners, with self-hosted runner support intended for a future release. [1]
  • GitHub Docs says a workflow or job needs permissions: id-token: write before it can request a GitHub OIDC JWT. [4]

Trusted publishing fixes one credential class, not every release risk

Bottom line: Use npm trusted publishing to remove long-lived publish tokens, then treat the release workflow as a production path: narrow id-token access, protect the trigger, pin third-party actions, and keep build steps separate from untrusted pull-request code.

npm Docs describes trusted publishing as a trust relationship between npm and a CI/CD provider using OpenID Connect. [1]

That shifts the publish decision from a static npm token to a specific CI identity. The release workflow still decides what code gets built, what package contents are packed, and which job can request the OIDC token.

Tokenless npm publish reduces secret storage pressure

npm Docs says trusted publishing allows packages to be published directly from workflows using OIDC authentication, eliminating the need for long-lived npm tokens. [1]

That matters because publish tokens are high-value secrets. Removing them from repository, organization, and environment secret stores reduces one common leak path, but it does not remove the need to review the workflow that can mint the short-lived publishing path.

Clean verdict: A tokenless release job is easier to rotate and audit when its trigger, environment, and permissions are narrow enough to understand during code review.

The OIDC permission belongs only on release jobs

GitHub Docs says workflows or jobs that need a GitHub OIDC token must set permissions: id-token: write, and that the setting allows the JWT to be requested from GitHub's OIDC provider. [4]

GitHub's workflow syntax reference says job-level permissions can modify the default GITHUB_TOKEN permissions for a single job, and that unspecified permissions become none after any permission is specified. [5]

For npm releases, that points to a small release job with explicit contents: read and id-token: write. Test, lint, and pull-request jobs should not carry id-token: write just because the repository has one publish workflow.

Provenance is evidence, not a review substitute

npm Docs says provenance statements publicly establish where and how a package was built, and who published it, so consumers can verify the package before download. [2]

The viewing-provenance guide says npm package pages can show build environment, workflow run, source commit, build file, and transparency-log details when provenance is available. [3]

That evidence is useful after release. It does not prove that the workflow was well-scoped, that dependencies were pinned, or that untrusted pull-request code could not influence the package before the release job ran.

The release workflow needs a small trust boundary

The trusted-publishing guide limits current runner support to cloud-hosted runners and says one package can have one trusted publisher configured at a time. [1]

Keep the trusted publisher bound to a workflow file that is easy to protect. Prefer release triggers that are reviewable, such as tags or GitHub releases created from protected branches, and keep broad shell generation out of the publish job.

Avoid this posture: A general automation workflow handles pull requests, writes repository state, requests id-token: write, and publishes to npm from the same job.

A fast npm release audit starts with the workflow file

List every workflow that can publish to npm. For each one, record the trigger, the trusted publisher configuration, whether it runs on GitHub-hosted runners, the job permissions, environment protection, third-party actions, package-build commands, and any path where pull-request input can affect release artifacts.

npm Docs says OIDC authentication supports npm publish and npm stage publish, while other npm commands such as install, view, or access still require traditional authentication methods. [1]

Run gha-guard locally so npm release review sits beside pinned-action, token-permission, timeout, pull-request trigger, OIDC, reusable-workflow, runner, cache, attestation, environment, dependency-review, shell-context, required-check, script-injection, allowlist, artifact-retention, fork-approval, concurrency, Dependabot, workflow_run, and checkout-credential audits.

This article is informational and is not a substitute for a security review of your own workflows, repositories, or cloud accounts.

CI Tripwire has not commissioned independent expert review of this article. Read more about the organization byline at contributors and the source posture at sourcing.

Corrections can be routed through the corrections note. Sources: 5 entries, primary npm and GitHub documentation, last reviewed 2026-06-08.

Sources

  1. npm Docs, Trusted publishing for npm packages.
  2. npm Docs, Generating provenance statements.
  3. npm Docs, Viewing package provenance.
  4. GitHub Docs, OpenID Connect in GitHub Actions.
  5. GitHub Docs, Workflow syntax for GitHub Actions.