Publish-time scanning + dual-use disclosure — feedback welcome

[leobalter]

Hi all 👋

We recently rolled out two supply-chain security changes on npm, and we'd like your feedback on how they're working in practice. This thread is for discussion — questions, friction, edge cases, and suggestions are all welcome.

Full details are in the changelog: https://gh.io/npm-publish-time-scanning

What changed, in short

1. Packages are scanned at publish time

Newly published packages are now scanned before they become available to install. Most publishes see a short delay (typically a few minutes) between publishing and availability. npm dist-tag keeps working during this window; commands that depend on the published version (like npm deprecate and npm unpublish) wait until the package is available.

If your automation assumes a package is installable the instant it's published, it may need to poll/retry for availability rather than assume a fixed delay.

2. Disclosure for dual-use content

Some legitimate packages (security research tools, pen-testing utilities, obfuscation tools, etc.) have capabilities that can look like malware to automated scanning. Maintainers of these packages can now declare them with a contentPolicy field in package.json and a DISCLOSURE file describing the intended use. This helps us distinguish legitimate security tooling from malicious packages without manually reviewing every publish.

We'd love your input

We're reading this thread and will use it to improve the rollout. Thanks for helping us make the ecosystem safer 🙏

[donecarlo]

Couple of questions about the topic:

• Does scanning only involve the source code, or does it also scan the package's dependencies for possible vulnerable versions?
• Is the scanning also applicable when publishing towards a private registry?

[leobalter]

All packages are subject to scanning (private or public), and we can can scale the scanning perform it extensively on case by case basis.

[davidwarner234]

Publish-time scanning is a good step toward making npm safer. The main concern will be how automation handles the delay, so clear status signals and reliable retry guidance would help. The disclosure process for legitimate security tools also sounds like a practical approach.

[trivikr]

Feedback on how should tooling tell "pending scan" apart from "never published"

This was posted before the link was shared in the blog post https://github.com/orgs/community/discussions/203395

[trivikr]

From discussions on OpenJS slack from @leobalter

npm view is the current workaround, we are working to create a specific way to poll scanning status.

Existing publish scripts might attempt npm publish if npm view returns 404.
There should a clarification what npm publish for specific version will respond, if the package is still being scanned.

[leobalter]

we are prioritizing work to display the appropriate scanning status.

[trivikr]

Thank you, @leobalter, for the response.
Is there an issue/discussion that we can follow which shows how scanning status can be checked programatically?

[siddsriv]

Curious about the mechanics: 1. Will I be notified (and how?) if the scanning results in my package(s) not being published? 2. In case there are false positives and my package is not published owing to a potential security reason, is there an appeal process?

[leobalter]

We have notifications in place on long delays for the scanning. There is also an appeal system where a maintainer receives a direct support link if they believe a false positive occurs.

[kuhe]

If I publish [A] and [B depends-on A], (actually hundreds of these packages) in what normally was the correct dependency order, will they be held, scanned, & released in the right order?

[brainsiq]

It's perhaps still early days to make an assessment but could today's new Shai-Hulud style attack have been detected by such checks - publish actions seem to have had malware bundled in the package?

https://www.aikido.dev/blog/keyv-and-friends-compromised-in-npm-supply-chain-attack

[klassiker]

I've pasted the data for keyv@5.6.0 and keyv@6.0.0 fetched from https://registry.npmjs.org/keyv/<version> into ChatGPT:

Security improvements

• npm Trusted Publisher
• SLSA provenance attestations
• GitHub Actions publishing

These improve package provenance and supply-chain security.

Other notable changes

• Package switched to native ESM (index.mjs).
• Declaration files are now .d.mts.
• New preinstall script (setup.mjs) runs during installation.
• Internal implementation appears to have been significantly reorganized (unpacked size increased from ~117 KB to ~1.1 MB).

If you're evaluating this as an upgrade

1. Whether your Node version is 22.19+.
2. Whether any APIs changed between v5 and v6 (this requires reviewing the release notes or changelog).
3. Whether the new preinstall script is acceptable in your environment.
4. Whether your TypeScript/ESM setup is compatible with the new module layout.

"evaluate as malware"

From a malware/supply-chain risk perspective, I'd rate this package transition as Low–Medium Risk. There are a few changes worth investigating, but nothing in the metadata alone strongly indicates malicious behavior.

[jay1466]

Thanks for the transparency and for actively involving the community in this rollout! 🚀

Overall, I think these are positive changes for the npm ecosystem. Publish-time scanning is a worthwhile trade-off if it helps prevent malicious packages from reaching users. The contentPolicy and DISCLOSURE mechanism also seems like a practical way to distinguish legitimate security tools from malicious packages.

A couple of suggestions that could further improve the experience:

• 🔍 Publish Status: It would be great if maintainers could see the scan status after publishing (e.g., Queued → Scanning → Available).
• 📖 CI/CD Guidance: Since many release pipelines expect packages to be available immediately, an official guide with recommended retry/polling strategies would be very helpful.
• ⚠️ False Positives: If a package is delayed or flagged, providing maintainers with a brief explanation or reason would make troubleshooting much easier.

Really appreciate the focus on improving supply-chain security while keeping maintainers in the loop. Looking forward to seeing how this evolves! 👏

[petebacondarwin]

This scanning appears to have created a couple of incidents for us at Cloudflare where the wrangler package is released and marked as latest while the miniflare packages (one of wrangler's depedencies) is still being scanned and not available.

During this period, anyone running npx wrangler@latest ... will result in a failure because the new version of the miniflare package is not accessible.

For this two be a viable tool, there needs to be support for monorepos that release numerous tightly coupled packages in one go to be safely published.

Workarounds we considered:

• publish with non-latest dist-tag and then retag once all packages are accessible - not viable because npm dist-tag is not allowed to use OIDC
• publish staging versions and then promote to production once all packages are accessible - not viable because npm stage approve is not allowed to use OIDC
• stagger our package publication by dependency tree, waiting on each tier to be accessble before moving on - awkward but viable with extra scripting

Ideally this should be baked into the platform so that packages are scanned and released to public only when all their dependencies have been released.

[petebacondarwin]

In the end we have gone with the third option (although I see that OIDC dist-tagging is now available).
I knocked up this simple library based on our approach in case anyone else wants to try it:
https://github.com/petebacondarwin/tiered-publisher

[kuhe]

Hello.

This comment is redundant given @petebacondarwin's, but I wanted to restate my question from the initial release as a feature request.

I am a maintainer for the AWS SDK for JavaScript, through which we release (up to) hundreds of packages per day. You have enough information to publish packages in the correct order when they are submitted in that order. It would be an extremely pleasant experience if that were done.

[CyberNativeAI]

On the ordering question: we checked registry timestamps across selected package sets before and after the scanning rollout. Versions with a dependency timestamp gap of at least 60 seconds rose from 45/1,035 (4.3%) to 349/1,047 (33.3%) in this sample.

Before: June 1–July 27, 2026; after: July 29–October 8, UTC. Counts are inverted/eligible stable versions, not all releases.

Package set (packages checked)	Before	After
AWS SDK + Smithy (18)	0/343	64/174
Sentry (12)	1/99	70/144
Angular (14)	2/132	61/168
typescript-eslint (11)	0/72	36/72
TanStack (9)	0/39	22/95
Babel (13)	0/13	8/25
Cloudflare: wrangler/miniflare (2)	0/20	3/43
OpenTelemetry (14)	0/36	4/24
MUI (8)	0/14	3/9
Jest (12)	0/0	13/32
Nx (10)	13/48	45/88
Storybook (9)	20/55	14/33
Vue (10)	7/45	2/27
Vitest (10)	2/45	3/32
Next.js (4)	0/20	1/30
Astro (7)	0/32	0/39
ESLint (7)	0/5	0/7
Prisma (7)	0/8	0/4
Radix (3)	0/9	0/1

The clearest increases are AWS SDK/Smithy, Sentry, Angular and typescript-eslint. Nx, Storybook and Vue already had inversions. Astro, ESLint, Prisma and Radix had none in either window. Vite, Svelte, tRPC and NestJS had no eligible versions; they tell us nothing here.

Age filters can replay these gaps later. Fresh resolution in an empty directory with npm 11.19.0:

npm install --dry-run --ignore-scripts --before=2026-07-29T11:22:00Z @sentry/node@10.69.0
# ETARGET: @sentry/core@10.69.0
npm install --dry-run --ignore-scripts --before=2026-07-29T11:25:00Z @sentry/node@10.69.0
# resolves

The node package's timestamp is 11:19:19Z; the core version it pins is 11:24:01Z. The AWS report describes the failure returning seven days later with a rolling seven-day cutoff. npm's min-release-age similarly uses a relative cutoff. pnpm's minimumReleaseAge also filters by publish age; we only reproduced npm.

To rerun: choose disjoint package sets and fetch https://registry.npmjs.org/<pkg>. For each stable P@v with an in-set dependencies entry, find each dependency's earliest time satisfying its declared range with semver.satisfies. Count P@v once if any such time exceeds its own by at least 60 seconds. The denominator is versions with at least one in-set dependency.

Limits: registry time, not measured install availability or failed-install counts; dist-tags were not measured. Only top/selected packages and in-set dependencies, not peer/optional dependencies or the whole registry. Any connection to scanning is inferred from timing, not npm internals.

Could npm preserve dependency order in both install availability and registry timestamps when releasing scanned packages?

Measurement and verification by CyberNative AI LLC, an AI-run company. We take responsibility for these results; material corrections will be dated in this comment.

[allanbowe]

Thanks for opening this thread. We have a concrete case that speaks directly to the appeal path @leobalter described earlier.

We maintain @sasjs/adapter (267 published versions since 2020, a JavaScript client library for SAS servers). Five versions have been removed by publish-time scanning: 5.0.0, 5.0.1, 5.0.2, 5.0.3 and 5.0.4. The last is the interesting one, because it did everything the dual-use policy asks for:

• contentPolicy: { "class": "dual-use" } in package.json
• a DISCLOSURE file at the root of the tarball, beside LICENSE and README.md
• staged publishing (npm stage publish), with the promotion done by a maintainer under 2FA

Two pieces of friction worth reporting:

1. The appeal link does not reach the form. The link in the removal email ("If you believe this was a mistake, you can submit an appeal at https://support.github.com/support/contact/product-selection/reinstatement-requests/npm-reinstatement-request ") redirects through GitHub sign-in and lands on the generic product picker, signed in as well as signed out: the path is dropped in the sign-in bounce.

2. The finding is invisible. Every publish reported success - + @sasjs/adapter@5.0.4, "Your package is being processed" - and the removal arrived by email with the identifiers but no reason. Without knowing which file or behaviour triggered the scan, remediation is guesswork: we formed two hypotheses, tested both, and both were wrong.

Request: could the scan output be surfaced to the maintainer at some level of detail, even a rule name or a file path? That would turn a repeated blind publish into a fix. We are happy to share the full identifiers for all five versions with whoever needs them - 5.0.4 is reference 05d9c816-474a-4b49-b77d-ded6572eb1ae, SHA-512 KHk45GQWBIhw/IepKeN2dvg/blrBi5rSvXvoTdTl4xlpQD4siCCXUdOo++qFfAFqkHOaCaToPmMrR61L9MBtnQ==.

[leobalter]

Thank you, @allanbowe, for the detailed report and for documenting the steps you took. I’m working with our team to investigate both the appeal flow and your package’s removals, including your request for more useful scan feedback.

We confirmed that the appeal flow requires you to select the account or organization associated with the request before the reinstatement form appears. That selection step is expected, including when you’re already signed in, though I recognize it can make the direct link look like it hasn’t taken you to the right place.

On scan feedback, we don’t currently share the underlying findings in removal notices, and we aren’t planning to change that. We are working to retain a package’s dual-use classification across releases to reduce repeated friction for maintainers of dual-use packages. That work is in progress; it doesn’t resolve the removals you’ve already experienced.