Software Supply Chain

npm Adds Multiple Trusted Publishers With Additive Authorization

By Kaleido Field Staff · September 6, 2026

Citation-ready: npm's multiple trusted-publishing configurations authorize a publish or stage when the incoming OIDC token matches any one independent configuration.

What happened and why it matters

The new configuration model removes the single-publisher constraint, but policy review must consider the union of permitted publishing paths. The broadest surviving match can still authorize an incoming token.

The dated source record

Primary reference: GitHub Changelog: Multiple trusted publishing configurations for npm. Kaleido Field checked the event date and the article's attributed facts against this source.

Read the policy as an OR expression

Imagine one configuration permits a release workflow and another permits a staging workflow. A token that meets either set of criteria can qualify. It is incorrect to expect the staging rule to add a condition to the release rule.

Review each entry on its own: identify its owner and intended release path, then decide whether it should still exist. A newly added narrow rule leaves an obsolete broad entry active until that entry is changed or removed.

Staging keeps a second decision before publication

Every configuration can stage by default; direct publishing requires an opt-in on that configuration. GitHub recommends staging. The approval control remains unavailable until malware scanning finishes, and maintainers can inspect staged-version history.

Scan completion is a timing gate, not an assurance that every malicious behavior is detectable. The approval reviewer still needs to understand the package diff, build provenance, and expected release before approving it.

The audit artifact is the complete configuration list

Preserve the full set of rules, their intended owners, direct-publish settings, and the expected approval path when reviewing a release setup. Do not build policy logic around rule evaluation order; GitHub says the order is not guaranteed.

Our evidence policy separates a documented control from a measured security outcome. This change supplies the former and gives maintainers a concrete configuration set to audit.

Evidence boundary

Official platform behavior, not a claim that OIDC or malware scanning prevents every package compromise. Rule-review examples below are editorial analysis. No exploit or independent security test was conducted.