A Registry That Stops Trusting Its Own Packages
npm v12 is now generally available and tagged latest, and it marks the most aggressive change to install-time behavior the registry has shipped in years. The headline is simple: dependency lifecycle scripts, the preinstall, install, and postinstall hooks that packages use to run arbitrary code during installation, no longer execute unless you explicitly allow them. Implicit node-gyp builds are off too. For a decade these hooks were the convenient way to compile native modules and wire up tooling, and also the single most reliable way for a poisoned package to run code on a developer laptop or a build agent the moment it landed.
We read this as npm formally abandoning the assumption that the code you install is code you can trust. The change arrives after a punishing run of supply chain incidents in the JavaScript world, where a single compromised maintainer account or a typosquatted dependency could seed an infostealer into thousands of downstream projects. By flipping the default from trust to refusal, GitHub is choosing to break a small number of builds today rather than absorb another wave of self-propagating worms tomorrow. That is a defensible trade, and one every other major registry is converging on.
Why Install Scripts Were the Soft Underbelly
The mechanics of the attack were always brutally simple. An attacker did not need a runtime exploit or a clever payload. They needed only to publish a version of a package that a victim would install, because installation itself ran their code with the full privileges of the user or the CI runner. That is how credentials, tokens, and source code walked out the door in incident after incident. The lifecycle hook was never a vulnerability in the traditional sense. It was a feature working exactly as designed, and the design was wrong for a world of automated, high frequency dependency updates.
npm v12 also closes two adjacent doors. Git dependencies are no longer resolved unless you pass an allow-git flag, and dependencies pulled from remote URLs require an allow-remote flag. Both were quiet vectors for pulling unpinned, unverifiable code into an otherwise locked build. The result is a package manager that treats every form of implicit execution as suspect until a human signs off. Developers who genuinely need a build step now run npm approve-scripts, review what wants to execute, and commit the resulting allowlist into package.json so the decision is explicit, auditable, and versioned.
The End of the Long Lived Publish Token
The second half of the release targets the publish side of the ecosystem, and it is arguably the more consequential shift for enterprises. GitHub is deprecating the most sensitive uses of granular access tokens configured to bypass two factor authentication. The rollout is phased. Around early August 2026, those tokens lose the ability to perform sensitive account, package, and organization management actions. Around January 2027, they lose the ability to publish directly at all, with publishing constrained to a staging flow that requires a human two factor approval step before a release goes live.
GitHub is blunt about the migration path. The company advises teams to move automated publishing to trusted publishing over OIDC, or to a staged publishing model with a human approval step, rather than relying on a long lived publish token. That is a direct assault on the pattern most CI pipelines use today, where a static npm token sits in a secrets store and quietly holds the keys to every package a team owns. Those tokens are the exact asset attackers hunt for, and they do not expire, rotate, or resist theft on their own. Removing them from the default workflow removes the prize.
Trusted Publishing Becomes the Default Path
Trusted publishing lets a CI system publish packages directly from a workflow using OpenID Connect, exchanging a short lived, workload bound identity for publish rights instead of presenting a stored secret. There is nothing to leak, because there is no persistent credential to steal. npm is implementing the trusted publishers standard defined by the Open Source Security Foundation, the same standard already adopted by PyPI and RubyGems. For once the JavaScript ecosystem is not inventing its own mechanism, it is joining an industry pattern, and that interoperability is worth as much as the security property itself.
For platform teams, the upshot is that identity is replacing secrets as the unit of trust in the release pipeline. A workflow proves who it is and what it is running, and the registry grants a narrow, ephemeral permission scoped to that proof. This is the same directional move we have watched play out in cloud IAM over the last several years, now arriving in package distribution. The teams that already treat pipeline identity as a first class concern will adopt this in an afternoon. The teams still copying tokens into environment variables have real work ahead.
What Breaks, and Who Feels It First
No default this sweeping ships without breakage, and honesty about that matters. Any project that quietly depended on a postinstall step to compile a native addon, patch a dependency, or fetch a binary will fail on first install under npm v12 until someone approves the script. Monorepos with sprawling dependency trees and internal tooling that leaned on git or remote dependencies will hit the new flags. The pain is front loaded and concentrated in exactly the complex, long lived codebases that large enterprises run, which is precisely where an unreviewed install script is most dangerous.
The practical response is to run the audit now rather than discover the failures in a production pipeline in August. Teams should pin the npm version their CI uses, inventory which dependencies genuinely require lifecycle scripts, and generate the approved allowlist deliberately instead of reflexively allowing everything, which would defeat the purpose. On the publishing side, the deprecation timeline is a gift of runway, not a suggestion. Moving to OIDC based trusted publishing before the January 2027 cutoff turns a forced migration into a planned one, and it is one of the highest leverage supply chain improvements a JavaScript shop can make this year.
