Protect publishing authority

Publishing credentials can replace trusted software for every consumer. Keep them out of developer laptops when the platform supports a safer path.

The threat is concrete. A long-lived registry token sits on a maintainer laptop and can publish every package in an organization. A stolen token lets an attacker replace trusted software without changing the repository. No pull request, no review, no trace in Git — just a malicious version on the registry. Several major npm compromises started exactly this way.

Audit what exists today

Start by listing the tokens that can publish right now:

npm token list

Every long-lived, broadly-scoped token in that list is an incident waiting for a laptop theft or a phished password. If a token must exist, make it a granular access token scoped to one package, with an expiry date — not a classic token that can touch everything you own.

Prefer identity over secrets

Trusted publishing removes the stored secret entirely. You register, on npmjs.com, which GitHub Actions workflow is allowed to publish the package. At release time the workflow proves its identity through OIDC and receives short-lived credentials for that one publish. There is no token to steal, because no token exists between releases.

Trusted publishing exchanges that reusable secret for a short-lived workflow identity. The workflow and release environment then become critical policy boundaries: protect them like the credential they now represent. Require review to change the release workflow, and put the publish job behind a protected environment:

jobs:
  publish:
    runs-on: ubuntu-latest
    environment: release
    permissions:
      id-token: write

The release environment can require named reviewers to approve each run, so high-impact publishing keeps a human gate.

Rotate whatever long-lived credentials remain, and test revocation before an incident — knowing the exact click that kills a token is response time you do not want to discover live.

Draw the identities from release approval to registry publication and save the effective permissions at every step. Configure or simulate a short-lived publisher limited to one package and protected environment. Then attempt publication from an unapproved branch and prove the registry or workflow rejects it.