GitHub Expands npm Trusted Publishing with Multiple OIDC Configs and Staged Malware Gates

GitHub announced the general availability of multiple trusted publishing configurations for npm packages, eliminating the longstanding constraint that limited each package to a single OpenID Connect (OIDC) configuration. Under this updated architecture, package maintainers can define separate, independent OIDC criteria across different repositories, workflows, and deployment environments to accommodate diverse release tracks, such as stable releases, prereleases, and staging builds. Simultaneously, GitHub enforced a security control within the staged publishing workflow: the approval button for staged releases remains disabled until backend publish-time malware scanning completes successfully. GitHub also integrated a full staged release history into the npm package versions tab. Securing software supply chains requires removing long-lived static credentials from continuous integration environments. Until now, engineering teams managing complex release pipelines were often forced to retain high-privilege static tokens or construct fragile CI workarounds when publishing from multiple branches or staging pipelines. By supporting multiple independent OIDC configurations per package, teams can now adopt short-lived, verifiable identity federation across all deployment tracks. Furthermore, coupling publish-time malware scanning with staged human approvals mitigates the risk of compromised CI runners or malicious dependencies slipping through expedited release cycles. This development reflects the broader industry movement toward cryptographically verifiable, tokenless CI/CD architectures championed by initiatives like SLSA and OpenSSF. As software supply chains face increasingly sophisticated automated injection attacks and token exfiltration attempts, package registries are shifting from permissive credential models to identity-bound, defense-in-depth verification. Enforcing automated inspection before granting human release authorization establishes a structured barrier against automated registry poisoning. In practice, DevSecOps and platform teams should immediately audit their npm release pipelines to identify and revoke any lingering static npm access tokens. Organizations should configure dedicated, granular OIDC trust profiles for each environment and establish staged publishing as the default baseline. By routing non-interactive CI builds into the staged queue and requiring both automated malware clearance and maintainer approval, organizations can harden their publishing lifecycle without disrupting continuous delivery.