npm now scans packages before release: what maintainers need to change

The npm registry now analyzes newly published packages before making them installable. A release can pass, be held for manual review or be blocked. For most projects, the process adds roughly five minutes between npm publish and actual availability; it can exceed fifteen minutes depending on size, content and service load.

That delay is small for a person but breaks pipelines that publish a version and immediately install, deprecate or promote it. npm is also introducing a mandatory declaration for dual-use tools whose legitimate security capabilities can resemble malware.

The short answer

Publishing is now asynchronous

Many scripts treated a successful npm publish as the moment a version became consumable. Scanning creates an intermediate state. npm dist-tag still works during analysis, but operations such as npm deprecate and npm unpublish wait until the package is available.

A resilient pipeline should query the registry with progressive backoff and a clear timeout. It should not blindly rerun npm publish, because the version already exists and a repeat attempt hides the real state. Downstream work starts only when the registry returns the expected version.

Projects publishing related packages also need to review ordering. If package B immediately depends on the new A, its installation test may fail during A's analysis window. A publication manifest or shared wait step prevents intermittent results.

Three outcomes after analysis

A package without suspicious signals becomes available normally. An ambiguous result may trigger manual review and a longer delay. Content identified as malicious can be blocked, and npm may take action on maintainer accounts based on severity and confidence.

Scanning does not guarantee a malware-free registry. Automated detection has false negatives and false positives. It adds a barrier at the most useful moment, before automated updates download the new release.

Consumers still need version locks, change review, Dependabot alerts, low-privilege execution and scrutiny of install scripts.

Dual-use tools must declare themselves

Penetration-testing, obfuscation and security-research packages can resemble offensive code. npm now requires a contentPolicy field with class dual-use in package.json, plus a text-only DISCLOSURE file at the root of the published package.

The file explains the sensitive capability and intended legitimate use. A declaration may trigger tailored scanning or human review. It is not automatic approval and does not legitimize a package primarily designed to cause harm.

Once published, the declaration must persist in later versions. Removing it requires Trust & Safety review. Maintainers should inspect the actual tarball with npm pack --dry-run, not merely confirm that the file exists in the repository.

Strong authentication becomes part of the release design

A dual-use package must use a method enforcing two-factor authentication. Interactive publishing with 2FA is accepted. Staged publishing followed by promotion also works because promotion enforces verification.

Direct publishing with a token that bypasses 2FA is not permitted. Trusted publishing through OIDC must use staging for this content instead of publishing directly. That detail can require changes to an otherwise working GitHub Actions or GitLab CI workflow.

The migration to make now

Maintainers should measure the delay between publication and installation, add a bounded polling loop and identify security-oriented packages separately. Monorepos should test cross-package dependencies in a prerelease environment instead of relying on the public registry during its analysis window.

Teams also need an appeal procedure: account owner, notification channel and evidence that can quickly explain detected behavior. A blocked Friday-night release should not depend on one unavailable maintainer.

npm is replacing instant availability with a control gate. The price is a few minutes and modest CI engineering; the potential benefit is stopping a malicious release before it enters thousands of dependency graphs.