Inventory the complete release authority
Assign a release owner to every package namespace and record registry administrators, maintainers, publisher identities, automation and recovery accounts. Include packages that are no longer actively developed but remain consumed. Reconcile registry membership directly with the employee and contractor inventory. Removing someone from a source repository does not prove their package-publishing account or token has lost authority.
Trace the release from reviewed commit to build command, package contents, registry upload and consumer loading behavior. Determine whether consumers bundle a fixed artifact or fetch mutable code at runtime. A dependency listed in a lockfile may still load another script from a CDN, so inspect runtime network behavior as well as the installation graph.
Use registry capabilities with narrow trust
npm documents trusted publishing using identity from supported CI providers and provenance statements that connect a publication to its source and build context. Follow the current provider and registry requirements, then restrict the configured publishing workflow and repository. Keep ordinary test jobs unable to publish, and remove redundant long-lived tokens after the new path is proven.
Our recommendation is to inspect the package before publication: generated files, installation hooks, bundled dependencies, secret scans and unexpected binaries. Compare the artifact with the approved release intent. Provenance helps answer where an artifact came from; it does not establish that its code is harmless or that the approved source was free of a malicious change.
Respond to a suspicious publication
Freeze release automation and identify the affected versions, publisher, source revision and download paths. Preserve the malicious artifact in a restricted evidence store without executing it. Coordinate registry and CDN response through established provider channels, and determine whether consumers already cached or bundled it. A removed registry version may remain present in an application artifact, mirror or browser cache.
Revoke affected publishing credentials and review registry membership, recovery methods and workflow changes. Publish a clear advisory with affected versions, safe migration guidance and the evidence available. Consumer instructions should address both removing the dependency and assessing what it could access while executing. Avoid asking users to run an improvised cleanup command from an unverified support message.
Exercise a release with no valuable authority
Use a sandbox package namespace to perform a normal release, a prohibited-branch release and an attempted publication by a removed test maintainer. Confirm the approved path works and the denied paths fail for an understandable policy reason. Inspect the resulting package and provenance from the consumer perspective, not only through the successful CI job log.
Repeat this exercise after organization changes, registry-policy changes or a new build system. Keep a documented emergency publisher recovery path with independent custodians. Review dependency updates for permissions and behavior, rather than accepting every update because it resolves an advisory count. Completion evidence includes the artifact digest, reviewed contents, publisher identity and proof that former release paths no longer work.
Controls to take away
- Source access and publishing access require separate offboarding checks.
- Provenance identifies a build path; it does not certify code safety.
- Runtime dependency loading can bypass a fixed build artifact.
Take this to your next review
Working checklist
Use this as a starting point, then assign owners and record evidence in your team's own system. Checks here reset when you leave or reload this note.
0 of 5 reviewed
Sources & further reading
The references below support this note. Adapt the procedures to your systems, access model and recovery requirements.
A correction or a better primary source? Send Raiders the article URL and evidence. Editorial policy.