Secretless release flows are a UX decision

The best secret is the one nobody had to paste into CI.

That sounds obvious until you look at how many release workflows still depend on long-lived tokens copied between a package registry, a password manager, a GitHub secret, and a YAML file that nobody wants to touch after it works once.

npm trusted publishing changes the shape of that workflow. GitHub's changelog says trusted publishing with OpenID Connect lets maintainers publish from GitHub Actions or GitLab CI/CD without npm tokens. npm's own docs say the model uses a trust relationship between the registry and the CI provider, with short-lived signed credentials tied to a specific workflow. The npm docs also say it currently supports GitHub Actions on GitHub-hosted runners, GitLab.com shared runners, and CircleCI cloud, while self-hosted runners are not supported yet.

Sources: GitHub changelog on npm trusted publishing, npm trusted publishers documentation, GitHub Actions OIDC hardening docs, OpenSSF trusted publishers specification.

This is a product design problem

Security teams usually describe this as token-risk reduction. Fair. Long-lived publish tokens can leak through logs, old laptops, copied environment files, and the kind of "temporary" debugging that survives for three years.

But the more interesting point is product design. Trusted publishing removes a task from the user's hands. It does not ask maintainers to become more careful. It makes the careful path the default path.

That is the part developer tools keep getting wrong. A lot of security UI is designed like a moral test: here is a dangerous token, here are sixteen warnings, good luck being an adult. Then everyone acts surprised when the token ends up in the wrong place.

A better interface removes the dangerous object from the routine path. The maintainer configures a trusted publisher once: owner, repository, workflow filename, and optionally an environment. The release job asks the CI provider for an OIDC identity token. npm checks that identity against the configured trust relationship. The publish happens without a reusable npm secret sitting in the repository settings.

Less ceremony. Fewer places to leak.

The workflow filename becomes part of the boundary

The detail I like is also the detail that will probably annoy people: the registry wants to know the workflow file.

In npm's GitHub Actions setup, the trusted publisher configuration includes the organization or user, repository, workflow filename, optional environment name, and allowed actions such as npm publish or staged publish. That is not only authentication. It is scope.

The package is not saying "anything from this GitHub account can publish." It is saying a specific workflow in a specific repository can publish this package. GitHub's changelog describes the result as workflow-specific credentials that cannot be exfiltrated and reused.

That moves release authority out of the secrets drawer and into the release architecture. The YAML file matters. The environment matters. The trigger matters. The protection rules around that environment matter.

This is where the UX gets sharper. The release path becomes inspectable. A reviewer can look at the workflow and ask boring questions that matter:

• Does this job run only on version tags?
• Does it request id-token: write only where publishing happens?
• Does it run tests before publish?
• Does an environment protection rule guard the package release?
• Does the package have exactly one trusted publisher configured?

Those questions are easier to review than "who has the npm token and where else did they paste it?"

Provenance should not be a bonus feature

GitHub's changelog says npm publishes provenance attestations automatically when trusted publishing is used. That matters because the release no longer has to be a black box. Consumers can verify where and how the package was built.

I like defaults like this. Most maintainers will not remember to add a provenance flag on every release path. They will copy a workflow from a README, adjust three lines, and move on. If provenance requires extra discipline, it will be uneven. If it comes with the safer publishing path, it becomes normal.

That is how developer tooling should treat security. Put the better behavior on the paved road.

There are limits. npm's docs say Node 22.14.0 or higher and npm CLI 11.5.1 or later are required. They also say self-hosted runners are not supported at the moment. GitHub's changelog notes provenance is unavailable when publishing from private source repositories. Those are not footnotes to ignore. They decide whether this pattern fits your release setup today.

Still, the direction is right. Tokenless publish is not magic. It is a narrower trust boundary with fewer reusable secrets.

What I would change in a release checklist

If I were auditing a small package today, I would stop treating "has an npm automation token" as the normal baseline.

The new baseline should be:

1. Use trusted publishing if the package and CI provider support it.
2. Keep release workflows small enough to review.
3. Put id-token: write only on the job that needs it.
4. Run install, build, and tests before publish.
5. Use environment protection for packages where a bad release would hurt users.
6. Check whether provenance is being generated and visible.
7. Keep old npm tokens out of CI unless there is a documented reason.

The human part of security does not disappear. Someone still has to review the workflow, protect the environment, and avoid turning the publish job into a junk drawer.

But the most failure-prone step is gone. Nobody copies a long-lived publish token. Nobody rotates it six months late. Nobody discovers it in a log after a bad night.

That is the UX lesson. Good developer tools do not only warn people away from mistakes. They redesign the path so the mistake is harder to make in the first place.