Status publishing in npm: approval with 2FA that stops automatic publishing and protects the supply chain

GitHub has activated a new npm tool called started publishing which requires manual approval of a maintainer (by double factor challenge) before a published version is visible and downloadable from npmjs.com. In practice, pre-built tarball is no longer made public at once: it rises to a staging tail and requires a person with publication access and 2FA to confirm its release. This small but significant modification seeks to add human presence test for each publication, including for devices generated by CI / CD.

The mechanism changes the traditional model in which a pipeline could automatically publish a version as soon as it ended: now the pipeline can upload the package with the command "npm stage publish" (available from npm CLI 11.15.0), but the version will not be installed until a maintainer exceeds the 2FA challenge. This mitigates scenarios in which misconfigured committed credentials or workflows allow the automated publication of malicious devices, because it requires an authenticated human interaction before the final push.

It is important to understand its limits: cannot be applied to new packages which do not yet exist in the register, requires the maintainer's account to have 2FA activated and the teams to update their client npm to 11.15.0 or more. In addition, control only raises the difficulty for automated attacks; it does not prevent an attacker who exceeds the 2FA of the maintainer (by phishing or access to tokens) from publishing malicious code. That's why GitHub recommends combining started publishing with trusted publishing using OIDC which reduces the dependence on long-term tokens in CI and improves the traceability of the identity of the pipeline.

In parallel, npm has added three flags to control installation origins no-record: --allow-file, --allow-remote and --allow-directory next to the existing one --allow-git. These options allow for a stricter permitted list strategy for facilities from local files, remote URLs or directories: controls that are useful to avoid malicious tarballs injections or the accidental installation of unverified source units from scripts or local tests.

For equipment and maintenance, the immediate practical recommendation is clear: active 2FA in all accounts with publication permits, updates the npm CLI to 11.15.0 +, and enables set publishing for critical packages. At the organizational level, it adopts OIDC for your CI / CD runners and eliminates long-term tokens; limits surviving tokens scopes; records and alerts unusual publishing activities; and uses additional signatures or verification mechanisms for artifacts where possible. Complete this with software composition analysis (SCA), mandatory change reviews and SBOMs generation for each build.

Do not forget to strengthen installation policies in development and production environments: consider by default denying facilities from URLs or files and explicitly allow only what is necessary through new flags, and educate developers about the risks of installing packages from external sources. These measures reduce the area by which massive "poisoning" campaigns - such as those recently attributed to groups that manipulate popular packages - manage to spread.

Staged publishing is not a panacea, but it represents a valuable advance in the defense of the open source ecosystem: it introduces a human control point that complicates automated attacks and improves the traceability of publications. For more information on software supply chain security practices and complementary recommendations see the official npm documentation at https: / / docs.npmjs.com / and resources on supply chain security such as the OWASP project in https: / / owasp.org / www-project-supply-chain-security /. It is also useful to follow GitHub's blog for updates and practical guides in this area: https: / / github.blog /.