npm Now Scans Packages at Publish Time: What Developers Need to Know

GitHub has updated npm to scan every new package for malware before it becomes installable, introducing a typical 5-minute delay between publishing and availability, with up to 15 minutes or more during peak times. Packages may be published normally, held for review, or blocked outright. A new contentPolicy field in package.json lets maintainers of legitimate security-relevant packages declare so-called "dual-use" content, though that declaration comes with its own requirements around two-factor authentication and a mandatory DISCLOSURE file.

What happened

Detail	Value
Typical publish delay	~5 minutes
Maximum delay (peak / large packages)	15 minutes or more
Possible outcomes after scan	Published, held for review, or blocked
New package.json field	contentPolicy
Required additional file for dual-use	DISCLOSURE (text only, in package root)
2FA requirement	Mandatory for all dual-use package publishes

As of late July 2026, npm scans every newly submitted package before it appears on the registry. GitHub announced the change as part of its ongoing supply-chain security work. The scan runs automatically; publishers do not need to opt in, configure anything, or change how they build packages.

The three possible outcomes are: normal publication, a hold for manual review by GitHub’s Trust and Safety team, or an outright block. If a package is blocked, the publisher may receive a notification with an option to appeal. GitHub notes that further action can be taken against maintainer accounts depending on the severity and confidence of the finding.

What does this mean for your publish pipeline?

For most packages, nothing changes except timing. The key caveat is automation. If any CI/CD script assumes a package is installable the moment the publish command exits, that assumption is now wrong. GitHub explicitly says to update those workflows to tolerate the delay.

A few operational notes worth flagging:

• npm dist-tag continues to work while a scan is pending.
• npm deprecate and npm unpublish will fail until the package is fully available.
• The 5 and 15 minute figures are typical behavior, not a service-level guarantee.

The new dual-use content policy

Some legitimate packages, such as penetration testing tools, exploit proof-of-concept code, or network scanners, have capabilities that look like malware to automated scanners. GitHub calls this “dual-use content.” Rather than blocking these packages by default, npm now offers a formal way to declare them.

To declare dual-use content, a maintainer must:

1. Add a contentPolicy field to package.json.
2. Include a plain-text DISCLOSURE file in the package root describing the dual-use functionality and its intended legitimate purpose.
3. Publish using a method that enforces two-factor authentication: trusted publishing via OIDC, an interactive session with 2FA active, or staged publishing.

Staged publishing is considered 2FA-enforced through its staging and promotion step, so granular access tokens that bypass 2FA can still be used to push to staging. Publishing directly to the main registry with a bypass token is not allowed for dual-use packages.

One rule to pay close attention to: once a package version carries dual-use metadata, every subsequent version must also carry it. Dropping the contentPolicy field or the DISCLOSURE file in a later version will cause that publish to be rejected. GitHub says this requirement will be enforced progressively, and maintainers of affected packages are being contacted by email.

Why it matters

Supply-chain attacks via malicious npm packages have become a consistent threat vector. Attackers routinely publish packages with names similar to popular ones (typosquatting) or compromise existing maintainer accounts to inject malicious code. Scanning at publish time, rather than relying on post-publication reports, closes a window that has been exploited repeatedly.

The dual-use framework is also significant. Previously, security researchers and red-team tooling authors had no official channel to signal intent. The DISCLOSURE file gives GitHub’s reviewers something to work with instead of making a binary call based on code patterns alone. If you maintain packages in the security tooling space, this is worth acting on before the default-block behaviour is fully enforced.

For teams that rely on npm packages in production pipelines, understanding how these changes interact with your web development or automation workflows is worth a quick audit now rather than a broken deploy later. Our earlier coverage of Microsoft’s AI security tooling rollout touches on how the broader ecosystem is tightening around supply-chain risk.

Our take

This is a sensible, overdue change. npm has been a soft target for supply-chain attacks for years, and the absence of publish-time scanning was a glaring gap. A 5-minute delay is a small price; most teams will barely notice it if their pipelines are written with any tolerance for latency.

The dual-use policy is more interesting. It asks security researchers to self-identify and accept extra scrutiny, which some will resist on principle. But the alternative, getting your package silently blocked with no appeal path, is worse. Our advice: if you maintain any package that touches network sockets, process execution, or credential handling in a way that could look suspicious out of context, add the contentPolicy declaration now, before enforcement tightens. The DISCLOSURE file takes ten minutes to write and could save hours of blocked-package headaches.

The biggest operational risk is in automated release pipelines that have hard assumptions about immediate availability. Check your CI/CD scripts today.

Source: GitHub Changelog