Publishing a package gives downstream users new code to install. A stored publishing token traditionally authorizes that operation. npm trusted publishing can instead establish a relationship with a supported CI provider, allowing a particular workflow identity to publish through an OIDC exchange.
This changes the credential path. It does not remove the need to control who can change the release workflow or what package contents that workflow produces.
Review the configured publisher identity
npm documents trusted publishing as an OIDC trust relationship between the registry and the CI provider. Supported provider behavior and configuration requirements are described in its maintained documentation. The npm trusted-publishing guide is the authoritative reference for those requirements.
For an illustrative internal tooling package, the review can match the configured repository and workflow to the actual release job. Similar names are not sufficient evidence. Record the exact identity conditions and who can modify them in both the repository and the package settings.
Package ownership remains an access decision
A release workflow operates within the registry's package and organization permissions. Review package maintainers, organization roles, and administrative recovery alongside the automated publisher. An alternate maintainer credential may still publish even if the main workflow has been restricted.
The migration inventory can distinguish active publishing paths, emergency procedures, and obsolete tokens. Removing a token from CI does not revoke a copy stored elsewhere. Revocation has to occur at the issuing service, followed by verification that the intended workflow still functions.
Inspect what the workflow packages
The published archive may include generated JavaScript, declarations, configuration, or other files that differ from the visible source tree. Record how the package is assembled and inspect its contents before release. Provenance can link a package to a build context without establishing that every included file was intended.
Use a test package or non-production release process to compare the packed file list with the approved distribution scope. Check that local environment files, development credentials, and unrelated build artifacts are excluded. This is a content check distinct from publisher authentication.
Verify unauthorized contexts are rejected
Test the approved workflow and controlled variants that do not match the publisher configuration. The expected result is that only the configured context receives publishing authority. Use a dedicated package so these tests do not create unintended public releases of a production dependency.
An assessment can then report the publishing identity, package contents, administrative access paths, and retirement status of older credentials. The evidence establishes how the reviewed release receives permission. It does not establish that the package is free of vulnerabilities or that every downstream consumer verifies its provenance.
Sources
npm: Viewing Package Provenance. The tooling package and test release are illustrative.
