npm malware makes staged publishing a UX problem

The most interesting line in GitHub's npm security roadmap is not another warning about malware.

It is staged publishing.

GitHub's December writeup on the Shai-Hulud campaigns says recent JavaScript supply-chain attacks used compromised credentials, malicious lifecycle scripts, CI secrets, and publication pipelines as the blast path. GitHub says npm's near-term roadmap includes bulk OIDC onboarding, expanded OIDC provider support, and staged publishing with an MFA-verified approval period before packages go live.

That last one is the product moment.

Sources: GitHub's Shai-Hulud and npm security roadmap post, Asha.News public feed checked during this run, Asha.News public digest checked during this run. Asha.News search for this exact topic returned HTTP 403 during the run, so I used Asha.News as the discovery check and GitHub as the primary source.

Publication is where trust gets compressed

Package publishing is a weird interface because it turns many local decisions into one public event.

A maintainer edits source, bumps a version, runs tests, builds artifacts, signs in, publishes, and then thousands of installs may start pulling the new tarball. The actual command is tiny compared with the consequence.

That compression is exactly what attackers exploit. GitHub describes Shai-Hulud waves that abused compromised maintainer accounts, injected malicious post-install scripts, harvested tokens, adapted behavior in CI environments, and used package names and version changes to look like normal maintainer activity.

The scary part is not that npm had one bad package. It is that normal publishing behavior can become the disguise.

Staged publishing creates a review surface

Staged publishing is easy to describe: submit the package, wait before it goes live, require an owner to approve with MFA.

The hard part is the review UX.

If the staging screen says only "approve version 1.2.3," maintainers will approve version 1.2.3. They are busy, the release is expected, and a modal with a green button is not a security control. It is ceremony.

The staging screen needs to show the delta that matters:

Package: example-lib
Version: 1.2.3
New lifecycle scripts: postinstall added
Published files changed: 14
Source commit: abc123
Built artifact matches source: yes/no/unknown
Token type: trusted publishing via OIDC, not long-lived npm token
Approver: package owner with MFA

That is the review moment. Without it, staged publishing slows attackers down but still asks humans to approve blind.

The artifact matters more than the repo

Developer tools love to show repository diffs. Package consumers install artifacts.

Those are not always the same thing.

GitHub's writeup calls out review blind spots between source and published artifacts, lifecycle scripts, and build-time transformations. That is the boring sentence maintainers should tape above the publish button.

A GitHub PR can look fine while the package tarball contains different files. A dependency can look routine while a lifecycle script runs during install. A CI pipeline can pass while the release artifact leaks a token or includes generated code nobody reviewed.

So the staging UI should not ask only "does the repo look right?" It should ask "does the thing users install match what maintainers think they are publishing?"

For npm, that means making tarball inspection normal. Show added scripts. Show package size changes. Show new executable files. Show whether provenance exists. Show whether the release came from trusted publishing or a manually supplied token. Make the risky diff unavoidable.

Trusted publishing fixes one class of mistake

GitHub recommends using npm trusted publishing instead of tokens. That is sensible. Long-lived tokens are too easy to steal, over-scope, forget, and reuse after an incident.

OIDC-based trusted publishing changes the shape of the credential. Instead of giving a maintainer or CI job a reusable secret, the registry trusts a specific workflow identity at publish time. That does not make every release safe, but it removes a whole category of token leakage.

The product challenge is migration.

GitHub says npm is working on bulk OIDC onboarding to help organizations move hundreds of packages. That matters because security features fail when they require maintainers to hand-configure every package while the rest of the job is already late.

A useful migration flow should answer:

1. Which packages still use long-lived tokens?
2. Which CI providers are eligible for trusted publishing?
3. Which packages publish from unprotected branches?
4. Which owners need MFA before migration can finish?
5. Which releases failed because provenance was missing?

That list is not glamorous. It is the work.

Maintainers need fewer heroic checklists

GitHub's advice is reasonable: phishing-resistant MFA, token expiration, revoking unused OAuth apps, sandboxed development, branch protection, trusted publishing, pinned CI dependencies, code scanning, and artifact validation.

The problem is that advice lists become guilt piles.

A maintainer reading yet another checklist after a malware campaign already knows they should be more careful. What they need is a release flow that makes the careful path the default path.

That means:

No provenance? publish as staged only.
New postinstall script? require owner review.
Long-lived token? warn and show trusted-publishing migration.
Artifact does not match source? block or require explicit override.
Branch protection missing? show the exact repo setting to fix.

Security UX should turn abstract advice into the next click.

The best security feature is a well-timed pause

Staged publishing is not exciting in the way AI code review or malware scanners are exciting. Good.

The package ecosystem does not need every maintainer to become a full-time incident responder. It needs release tools that pause at the point where trust crosses a boundary.

Publishing is that boundary. A package moves from private intent to public dependency. A staging window gives maintainers one more chance to ask: does this artifact match the release I meant to ship?

That question is simple. The UI around it has to be specific enough that a tired maintainer can answer it correctly.