The 18-month stretch from late 2024 through early 2026 was the most consequential period in npm's history for supply-chain security. A series of incidents — typosquatted packages stealing wallet keys, postinstall scripts exfiltrating environment variables, malicious updates pushed via compromised maintainer accounts, and a particularly damaging incident where a popular utility package was sold to an actor who modified it weeks later — forced a coordinated response from npm Inc., the package maintainer community, and the major JavaScript framework projects. The result is a meaningfully different ecosystem in 2026 than the one most teams remember. This article maps what changed, what every production team should now have in place, and the specific verifications that distinguish a hardened npm workflow from a vulnerable one.
The Five Incidents That Forced the Change
Each of these incidents was independently significant; together they made supply-chain security an unavoidable engineering concern rather than a theoretical one. Understanding the specific failure modes helps frame why each of the subsequent ecosystem changes was necessary.
- Q4 2024 — A popular wallet-related package was updated to exfiltrate seed phrases from any project that included it. Affected thousands of downstream applications.
- Q1 2025 — A maintainer of a widely-used CLI utility had their npm credentials phished; a malicious version was published and pulled by tens of thousands of CI runs before takedown.
- Q2 2025 — A typosquatted package mimicking a popular React component library accumulated 200K downloads before discovery; postinstall script harvested CI environment variables including AWS keys.
- Q3 2025 — A "for-sale" package with low download count but high reverse-dependency leverage was acquired by an attacker through a legitimate-looking transaction; modified six weeks later.
- Q4 2025 — A major framework had a bundled dependency replaced upstream through a transitive-package compromise; the framework itself was clean but every project using it shipped malicious code for ~48 hours.
What Changed: Sigstore and Provenance
The most significant ecosystem-level response was the rapid rollout of Sigstore-based package provenance. By Q4 2025, the major framework packages — React, Vue, Next.js, Angular — were all publishing signed attestations linking each npm release to a specific GitHub Actions build in a specific repository. By mid-2026, npm itself shows a "Provenance" badge on the package page for any package that publishes with attestation. This does not prevent malicious packages from being published, but it makes provenance verifiable: you can confirm that a package version was built from a specific commit by a specific build pipeline.
- Major frameworks (React, Vue, Next.js, Angular, Svelte) now publish signed provenance for every release
- npm displays a visible Provenance badge on package pages and in `npm view` output
- CI tooling can verify provenance at install time — opt-in today, default in npm 12 (expected late 2026)
- Provenance does not vouch for safety, only for source — a malicious commit in a legitimate repository still produces "valid" provenance
- Enterprise teams are increasingly requiring provenance for any production-included package as part of supply-chain policy
What Changed: Scoped Tokens and Granular Permissions
After the maintainer-account compromise incidents, npm rolled out scoped automation tokens that restrict what a stolen credential can do. The default token for CI publishing in 2026 can be limited to specific packages, specific operations (publish-only, not modify-team), and specific origin IP ranges. This dramatically shrinks the blast radius of a credential leak — a CI token configured correctly cannot, for example, publish a new package or modify team membership even if exfiltrated.
- CI publishing tokens should be scoped per-package with publish-only permissions
- Personal access tokens should be reviewed and pruned quarterly
- 2FA on every npm account that has publish permissions to any production-included package — this is now table stakes
- IP-restricted tokens for publishing from GitHub Actions runners with stable IP ranges
- npm Trusted Publisher integration (OIDC-based, no long-lived token at all) for the security-conscious — adopt this if you publish packages
What Changed: Lockfile Audit Becomes Default
npm 11 (shipped Q1 2026) changed `npm install` defaults: if a `package-lock.json` exists, the installer verifies integrity hashes against the lockfile and fails by default if they do not match, instead of silently fetching from the registry. This is the kind of small default change that has outsized consequences — most maliciously-published versions are caught by this verification because the attacker cannot retroactively update lockfiles in downstream repositories. Teams that previously had lockfile-audit disabled or were running on older npm versions should treat the upgrade as urgent.
- npm 11+ verifies lockfile integrity by default — upgrade to npm 11 if you have not
- package-lock.json should be committed for every project including libraries (the recommendation flipped on this in 2025)
- CI should run `npm ci` (strict lockfile mode) not `npm install` — this was best practice before, now it is non-negotiable
- `npm audit signatures` checks Sigstore provenance for packages that publish it — opt-in today, useful now
- Custom registries (Verdaccio, JFrog, GitHub Packages) should mirror upstream with verification, not just cache
What Every Team Should Have in Place by Now
The checklist below is what we consider table stakes for any production engineering practice using npm in 2026. None of these items are expensive or sophisticated; all of them are documented and well-understood. Teams without these in place are operating with security controls that the ecosystem and major framework projects have collectively decided are no longer optional.
- npm 11+ on every CI runner and developer machine
- package-lock.json committed for every repository — yes, including libraries
- `npm ci` in CI pipelines, never `npm install`
- 2FA on every npm account with publish access to any production-included package
- Scoped automation tokens for CI publishing — no broad personal tokens in CI
- Dependency review on PRs that modify package.json — automated via tools like Dependabot, Renovate, or Socket.dev
- Quarterly review of installed dependency count — every dependency is supply-chain risk; minimize aggressively
- CVE response process with documented SLA (see our companion guide on building this for small teams)
- Verification of provenance for at least your top 10 direct dependencies
The Five Habits That Distinguish Hardened Teams
Beyond the checklist, the difference between teams that have absorbed the new ecosystem reality and teams that have not shows up in five specific habits. These are cultural rather than technical, and they predict supply-chain security posture better than any single tool or configuration.
- Adding a dependency is a decision, not a reflex — every new package gets a brief written justification, especially for transitive-heavy ones
- Periodic dependency audits — quarterly review of every direct dependency: do we still need it, is it still maintained, is there a smaller alternative
- Treat postinstall scripts as code review — disable them globally where possible (npm config set ignore-scripts true) and enable case-by-case
- Vendor critical small utilities — if a single-function package has reverse-dependency-leverage in your stack, consider vendoring rather than depending
- Subscribe to advisory feeds and treat them as production signals — the team that learns about the next incident first has the most options
Conclusion
The npm ecosystem in 2026 is materially more defensible than it was in 2024 — but only for teams that have absorbed the changes. Provenance attestation, scoped tokens, lockfile audit, and the cultural shift toward treating dependency additions as supply-chain decisions are all available; using them is the difference between being part of the modernized ecosystem and being a sitting target. The incidents that drove these changes have not stopped; they will keep happening. The teams who have implemented the controls described above will absorb them as small annoyances. The teams who have not will absorb them as breaches. The cost differential between those two outcomes is the strongest argument for taking the time, this quarter, to upgrade the workflow.
About Sensussoft Engineering
Sensussoft Engineering is a technology expert at Sensussoft with extensive experience in devops & security. They specialize in helping organizations leverage cutting-edge technologies to solve complex business challenges.
