GitHub Expands npm Trusted Publishing with Multi-OIDC Workflows and Malware Gates

GitHub has officially released three significant enhancements to npm trusted publishing: support for multiple OpenID Connect (OIDC) configurations per package, mandatory completion of publish-time malware scanning before staged package approval, and a visible staged history log within the npmjs.com package versions interface. Maintainers can now register multiple independent and additive trusted publisher configurations for an individual package, each mapping to distinct repositories, environments, and CI workflows. Furthermore, newly created configurations default to staged publishing, where direct publishing must be explicitly enabled and manual approval remains blocked until registry-side malware analysis completes. For DevSecOps practitioners and open-source maintainers, this change addresses a long-standing operational vulnerability in artifact publishing pipelines. Previously, because npm restricted packages to a single trusted publisher configuration, engineering teams running separated release tracks—such as nightly builds, staging candidates, and production releases—were frequently forced to retain long-lived, static access tokens to bypass OIDC constraints. By enabling multiple discrete OIDC bindings, organizations can enforce strict least-privilege boundaries across different branch workflows without exposing static credentials that could be leaked or stolen from CI execution environments. This update aligns with the broader software supply chain security movement led by OpenSSF, SLSA frameworks, and modern artifact registries moving toward tokenless, keyless authentication. Regulators and enterprise standards increasingly demand cryptographically verifiable provenance throughout the software development lifecycle. By shifting away from shared credentials and coupling identity federation with deterministic security checks like automated malware scanning, package registries are transforming from passive code stores into active enforcement points against pipeline compromises and malicious package injection. In practice, security engineers and pipeline maintainers should audit existing npm publishing setups and accelerate the migration away from legacy static npm tokens. When configuring multiple OIDC publisher entries, teams must recognize that npm evaluates trusted publisher rules additively without enforcing an evaluation order; an overly permissive configuration can inadvertently bypass restrictions set by another. Teams should keep the default staged publishing enabled for non-automated releases, implement fine-grained GitHub environment protections, and ensure that only hardened, tag-triggered production workflows possess direct publishing privileges.