Listen to this Post
Introduction
The JavaScript ecosystem has long faced one major problem: supply-chain attacks hidden inside trusted packages. Over the last few years, attackers have repeatedly abused npm packages to spread malware, steal credentials, and compromise developer environments. Now, npm
is introducing a significant shift in how packages are published and installed.
With the release of npm CLI 11.15.0, the platform unveiled two major security-focused improvements designed to strengthen developer trust and reduce risks across the open-source ecosystem. The first is “staged publishing,” a system that forces human approval before packages go live. The second introduces new installation control flags that let developers restrict where dependencies can come from during package installation.
Together, these changes represent one of npm’s strongest security pushes in recent years and signal a broader industry movement toward zero-trust software supply chains.
npm Introduces Staged Publishing for Stronger Security
The most important announcement is the general availability of staged publishing. Traditionally, when a maintainer used npm publish, the package instantly became available to millions of users worldwide. While fast and convenient, this system also created opportunities for compromised accounts, malicious CI/CD pipelines, or hijacked automation workflows to publish harmful code almost instantly.
The new staged publishing workflow changes that process entirely.
Instead of immediately releasing a package, npm now uploads the prebuilt tarball into a staging queue. The package remains inaccessible to users until a maintainer explicitly approves it. This approval requires proof of presence through two-factor authentication, ensuring that a real human verifies the release before it reaches the public registry.
This is particularly important for automated CI/CD systems that use trusted publishing and OIDC authentication. Even if an automated workflow publishes a package, a human maintainer must still approve it manually before the release becomes active.
How the Staging Queue Works
The staging queue is accessible directly through npm’s website and also through the npm CLI itself. Developers using npm CLI version 11.15.0 or newer can replace traditional publishing commands with:
Bash
npm stage publish
This command uploads the package into the review queue instead of instantly releasing it.
Once uploaded, maintainers can inspect the package, verify the contents, and approve the release from a trusted device. This extra layer may appear small, but it dramatically reduces the likelihood of unauthorized or malicious releases slipping into production.
Why This Matters for Open-Source Security
Open-source repositories have become one of the largest attack surfaces in modern software development. Many organizations rely on thousands of indirect dependencies, often without fully auditing them.
Attackers understand this perfectly.
Recent years have seen multiple incidents where compromised npm packages injected credential stealers, cryptocurrency miners, and remote-access malware into developer systems. In some cases, malicious updates remained undetected for hours or even days while thousands of users unknowingly installed infected packages.
By requiring explicit human approval, npm is attempting to close one of the most dangerous gaps in automated publishing pipelines.
Recommended Setup for Developers
npm recommends combining staged publishing with trusted publishing using OIDC authentication. In this model, automated CI systems can only stage releases rather than publish them directly.
That means:
CI/CD pipelines continue running automatically
Builds remain fully automated
Final release approval requires a maintainer
Human verification becomes mandatory
This hybrid workflow balances automation speed with strong security controls.
Organizations already using npm’s bulk trusted publishing management system, introduced earlier in 2026, can also migrate existing packages into staged publishing workflows.
New Install Source Flags Add Granular Dependency Controls
The second major security feature involves stricter installation source controls.
Previously, npm introduced the –allow-git flag to control installations from Git-based sources. Now, npm has expanded this idea by introducing three new flags:
Bash
–allow-file
–allow-remote
–allow-directory
These options allow developers and organizations to decide exactly which installation sources are permitted during dependency resolution.
Understanding the New Flags
Each flag targets a different source type:
–allow-file
Controls installations from local file paths and local tarballs.
–allow-remote
Controls installations from remote URLs, including HTTPS tarballs.
–allow-directory
Controls installations directly from local directories.
–allow-git
Controls installations from Git repositories, including GitHub, GitLab, git+ URLs, and shorthand repository references.
Each option accepts either:
Bash
all
or
Bash
none
Developers can configure these values in .npmrc or directly inside package.json.
npm Is Quietly Moving Toward Zero-Trust Installs
One of the most important details in npm’s announcement is its future plan for stricter defaults.
npm confirmed that in CLI version 12, the default behavior for –allow-git will change from:
Bash
all
to:
Bash
none
This means Git-based installations will eventually become blocked unless developers explicitly allow them.
That change reflects a much larger industry trend: software ecosystems are moving away from implicit trust models and toward explicit authorization systems.
In other words, package managers increasingly assume external sources are potentially dangerous until proven otherwise.
What Undercode Says:
The Real Target Is CI/CD Infrastructure
npm’s latest move is not just about package publishing. It is fundamentally about defending CI/CD infrastructure from silent compromise.
Modern development pipelines are heavily automated. Attackers no longer need to breach production servers directly if they can poison the build pipeline upstream. By compromising publishing workflows, threat actors can distribute malware to thousands of downstream applications automatically.
The staged publishing model directly attacks this threat vector.
Human Approval Is Becoming the New Security Standard
The requirement for human approval may initially frustrate developers who prioritize release speed. However, the cybersecurity industry is increasingly embracing “human-in-the-loop” verification for critical operations.
We already see this approach in:
Banking systems
Cloud infrastructure management
Enterprise IAM workflows
Hardware security modules
npm is now applying the same philosophy to package publishing.
Attackers Love Automation
The biggest weakness in modern DevOps environments is excessive trust in automation.
If a malicious actor steals a CI token or compromises an automation runner, they can potentially push poisoned packages without ever touching a maintainer’s personal account.
Staged publishing dramatically weakens that attack chain because automated systems alone are no longer enough.
Dependency Sources Are a Massive Blind Spot
The new install source flags may appear minor compared to staged publishing, but they are equally important strategically.
Many organizations unknowingly allow dependency installations from arbitrary Git repositories, remote tarballs, or local paths. These sources often bypass traditional registry security scanning entirely.
Blocking unnecessary installation sources can significantly reduce exposure to supply-chain attacks.
npm Is Learning From Previous Ecosystem Failures
The JavaScript ecosystem has suffered repeated security incidents involving typosquatting, dependency confusion, and malicious package updates.
Some attacks specifically exploited alternative installation methods outside the central npm registry. The new –allow- controls are clearly designed to reduce those risks.
Security Will Eventually Override Convenience
Developers often resist security changes when they introduce friction. But history consistently shows that ecosystems eventually prioritize safety over convenience after enough large-scale incidents occur.
npm appears to be acting before another catastrophic supply-chain attack forces emergency changes later.
Enterprise Adoption Will Likely Accelerate
Large enterprises are expected to adopt staged publishing quickly because compliance teams increasingly demand provable release validation processes.
Manual approval workflows align well with:
SOC 2 requirements
Supply-chain auditing
Internal release governance
Secure software development frameworks
This makes staged publishing attractive far beyond individual open-source maintainers.
Smaller Projects May Initially Ignore These Features
While enterprises will likely embrace these changes rapidly, many smaller open-source maintainers may delay adoption because manual approval adds extra operational steps.
However, once security-conscious users begin preferring packages with staged workflows, broader adoption could accelerate naturally.
The Bigger Industry Message Is Clear
npm’s announcement signals something much larger than a simple CLI update.
The era of blindly trusted package ecosystems is ending.
Every major software ecosystem is now moving toward:
Signed packages
Human verification
Restricted dependency sources
Provenance validation
Zero-trust distribution pipelines
npm is positioning itself ahead of that transformation.
Deep Analysis
Staged Publishing Could Reduce Mass Exploitation Windows
One overlooked benefit of staged publishing is the reduction of exploitation speed.
Previously, attackers could compromise an account and instantly distribute malicious updates globally. Now, even if publishing credentials are stolen, attackers still face a manual approval barrier.
That delay alone could prevent widespread automated malware campaigns.
Developers May Need Workflow Redesigns
Many organizations built fully automated release systems around direct publishing. Adopting staged publishing may require redesigning deployment pipelines, approval chains, and release management policies.
This transition could temporarily slow release velocity for some teams.
Security Teams Will Gain More Visibility
Approval queues create valuable audit trails.
Security teams can now monitor:
Who approved releases
When approvals occurred
Which device was used
Which packages entered production
This improves incident investigation capabilities dramatically.
The New Flags Encourage Principle of Least Privilege
The install flags reinforce a fundamental security principle: only allow what is explicitly necessary.
Most applications never truly need installations from arbitrary remote tarballs or local directories. Restricting these by default lowers unnecessary risk exposure.
Attackers Will Adapt
Cybercriminals will inevitably search for ways around staged publishing. Social engineering attacks against maintainers may increase as attackers attempt to manipulate approval workflows instead of automation systems.
The security battle is evolving rather than ending.
🔍 Fact Checker Results
✅ npm CLI 11.15.0 Introduced Staged Publishing
The feature is officially available and requires npm CLI 11.15.0 or newer.
✅ New –allow- Flags Were Added
npm added –allow-file, –allow-remote, and –allow-directory alongside the existing –allow-git flag.
✅ Git Install Restrictions Will Tighten in npm v12
npm confirmed that the default value for –allow-git will change from all to none in the next major CLI release.
📊 Prediction
npm’s Security Changes Will Push Other Ecosystems to Follow
npm’s staged publishing model could influence other package ecosystems like PyPI, RubyGems, and Cargo to adopt similar human-approval workflows. Supply-chain attacks are now one of the biggest threats facing software development, and centralized package repositories are under growing pressure to strengthen verification systems.
Security-Focused Maintainers Will Become More Trusted
Projects using staged publishing, trusted publishing, and strict dependency controls may eventually gain higher credibility among enterprise users. Security posture could become a competitive advantage inside open-source ecosystems.
Fully Automated Publishing May Slowly Disappear
As software supply-chain attacks continue increasing, fully automated publishing pipelines without human verification may become viewed as outdated and risky, especially for widely used packages and enterprise-critical libraries.
🕵️📝Let’s dive deep and fact‑check.
References:
Reported By: github.blog
Extra Source Hub (Possible Sources for article):
https://www.digitaltrends.com
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
Bing
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube
