SOFTWARE / SYSTEMS / AIEngineering news. Technical depth.
NEWS / Security · 2 MIN READ

npm allows multiple trusted-publishing configurations per package

Maintainers can authorize several independent OIDC workflows, keep each staging-only by default, and wait for malware scanning before approval.

Announcement: · From GitHub

npm made multiple trusted-publishing configurations per package generally available on September 3. A maintainer can now authorize separate OIDC identities for stable, prerelease, or staging workflows without preserving a long-lived token for the extra paths. GitHub’s announcement says each configuration independently matches repository, workflow, and environment criteria.

Several identities can share one package safely

Configurations are additive: a publish is authorized when its OIDC token matches any one of them, and evaluation order is not guaranteed. That makes each entry a complete grant rather than a rule that narrows another rule. Maintainers should avoid overlapping criteria that make it unclear which workflow was intended to publish a version.

Every trusted configuration can stage by default, while direct publishing must be enabled explicitly. Keeping workflows staging-only preserves the human, two-factor-authenticated promotion step introduced with staged publishing. It also separates compromise of a CI identity from immediate public release.

Scanning joins the promotion state machine

npm now disables approval of a staged package until publish-time malware scanning completes. The versions tab records whether a staged version was approved, rejected, or remains pending. That history can support incident review, but a completed scan is not a guarantee that a package is benign.

Inventory current package publishers before adding configurations. Give stable and prerelease workflows distinct environments and branch or tag protections, then test that an unauthorized branch cannot obtain a matching token. Remove superseded grants instead of accumulating them indefinitely. Approvers should compare package contents, source commit, provenance, version, and expected workflow before promotion. Multiple OIDC routes solve a practical automation constraint; they also increase the authorization surface, so each route needs a named owner and periodic review.

SOURCES & CONTEXT

See the original announcement for availability and release details.