GitHub has expanded the npm trusted publishing feature so a single package can now hold several independent OIDC configurations. This removes the previous one‑configuration limit, lets teams separate stable, prerelease, or staging workflows, and keeps the same approval and scanning safeguards.
New Configuration Model
Each configuration is defined by its own repository, workflow, and environment criteria. You can add, list, or delete configurations from the package settings page. During a publish or stage operation, the incoming OIDC token is checked against all configurations; if any match, the request is authorized. The order of evaluation is undefined, so logic must not depend on which configuration wins.
Staged Publishing and Malware Scanning
All configurations can stage packages by default; direct publishing must be enabled per configuration. Staging inserts a manual approval step before a version becomes visible, protecting the registry from a compromised CI pipeline that might otherwise push malicious code. Since the introduction of publish‑time malware scanning, a package is scanned before it leaves the staged queue. The approval button stays disabled while scanning and is re‑enabled once the scan finishes, with the UI refreshing status every minute.
Visibility into Staged History
The npmjs.com versions tab now shows maintainers a per‑version log indicating whether a version was approved, rejected, or remains staged. This historical view helps teams audit the flow of releases and verify that the staging gate operated as expected.
Related CloudNinjas coverage: DevOps.
What This Means For Practitioners
Architects should consider splitting publishing pipelines into distinct OIDC configurations to isolate release streams without sharing long‑lived tokens. Security engineers can rely on the mandatory staging step and built‑in malware scan as a baseline defense against supply‑chain attacks, but must still monitor the staging queue for delayed scans. Operations teams need to adjust automation to handle the disabled approval button during scanning and to poll the status at the one‑minute interval the UI uses. Finally, reviewers should verify that any direct‑publish opt‑in is intentional and limited to configurations that truly need it, keeping most workflows in staging‑only mode.
