https://github.blog/changelog/2026-05-22-staged-publishing-and-new-install-time-controls-for-npm/
GitHub has released two significant security updates for npm, the world’s largest software package registry and the primary distribution channel through which JavaScript developers share and consume reusable code components.
The first update, called staged publishing, introduces a mandatory human approval step between a software package being built and that package becoming available for others to download and use. Previously, an automated build system could publish a new package version directly to the registry the moment it finished compiling, with no human review required. Under the new model, the package enters a waiting queue and a named maintainer must physically approve its release using a two-factor authentication challenge from a trusted device before it becomes publicly available. The second update gives development teams explicit control over where their software is permitted to fetch dependencies from during installation, allowing organisations to block their projects from pulling code from unapproved sources such as arbitrary remote URLs, local file paths, or external Git repositories.
The practical significance of these changes is best understood in the context of the supply chain attacks that have made headlines in recent weeks. The Mini Shai-Hulud campaign, which compromised packages downloaded millions of times each week, and which led to the breaches of both Grafana Labs and GitHub itself, succeeded in large part because attackers who obtained stolen automated credentials could publish malicious software versions directly to public registries with no human ever reviewing what was being released. The staged publishing control closes that specific attack pathway: even if a threat actor steals a valid publishing credential from a compromised build pipeline, they cannot complete a malicious release without triggering an authentication challenge to a real person.
The human approval gate requires a change to how automated build pipelines publish software, and that change needs to be planned and tested rather than applied without preparation. The install source restrictions, meanwhile, can be configured at the project level today and offer a meaningful reduction in the risk that a compromised dependency quietly pulls additional malicious code from an external location during a routine software build.