Listen to this Post
Introduction
Software supply chain attacks continue to evolve at an alarming pace, especially across the JavaScript ecosystem where npm packages power millions of applications worldwide. Threat actors increasingly target package maintainers, CI/CD systems, and dependency distribution channels to inject malicious code into trusted software environments. In response to these growing risks, GitHub has introduced two major security enhancements for npm that aim to strengthen package integrity and reduce the likelihood of compromised releases reaching developers.
The new protections include staged publishing, now officially available for production use, and expanded installation source restriction controls integrated into npm CLI 11.15.0, released on May 22, 2026. Together, these updates introduce stronger human verification requirements and tighter dependency source governance designed to reduce software supply chain exposure.
GitHub Introduces Staged Publishing for npm
GitHub’s staged publishing system significantly changes how packages are published to the npm registry. Traditionally, package maintainers could publish updates directly, making them immediately available to developers globally. While efficient, that model created opportunities for attackers to distribute malicious packages rapidly after compromising maintainer credentials or automation pipelines.
The new staged publishing process creates an intentional checkpoint. Instead of instantly releasing a package version to npm users, the package tarball first enters a staging queue. A maintainer must then complete a two-factor authentication verification process before the release becomes publicly installable.
This additional approval layer introduces what GitHub describes as “proof of presence.” The concept ensures that a verified human explicitly authorizes publication, even when releases originate from automated systems such as CI/CD pipelines or OpenID Connect trusted publishing workflows.
Maintainers can now review pending releases directly through npm CLI tools and npmjs.com interfaces before publication occurs. This added visibility helps organizations detect suspicious publishing behavior before malicious code reaches downstream environments.
Requirements for Using Staged Publishing
GitHub established several prerequisites before maintainers can adopt staged publishing:
Existing Registry Presence
Packages must already exist on the npm registry. Newly created packages cannot use staging initially.
Verified Publishing Permissions
Maintainers must have confirmed publishing access to the package.
Mandatory Two-Factor Authentication
Accounts publishing through staging must have two-factor authentication enabled.
Updated npm Client Requirement
Organizations must upgrade to npm CLI version 11.15.0 or newer.
These conditions ensure security controls are enforced consistently across participating projects.
CI/CD Automation Gets Stronger Protection
One important advantage of staged publishing is compatibility with automated deployment pipelines. Development teams increasingly rely on CI/CD systems for rapid software delivery, but automation can become dangerous when credentials are compromised.
GitHub recommends pairing staged publishing with OpenID Connect trusted publishing configurations. Under this approach, CI/CD pipelines execute publishing workflows normally but cannot finalize public distribution independently.
Instead of using direct publishing commands, organizations configure pipelines to use:
npm stage publish
This workflow preserves automation efficiency while requiring final human verification from a trusted device before release completion.
The security improvement directly targets scenarios where attackers compromise build systems and inject malicious code into software packages without maintainer awareness.
npm Adds Expanded Dependency Source Restrictions
Beyond publishing protections, npm CLI 11.15.0 expands dependency installation controls with new allowlist-based restriction flags.
The npm ecosystem previously introduced:
–allow-git
Now the security model expands with three additional controls:
–allow-file
Controls installation from local file paths and local tarball packages.
–allow-remote
Regulates package installation from remote URLs, including HTTPS-hosted tarballs.
–allow-directory
Manages installation permissions originating from local directories.
–allow-git
Continues governing dependency retrieval from Git repositories including GitHub, GitLab, and Git-based URLs.
Each setting supports either:
all
or
none
Organizations can configure restrictions within .npmrc files or directly inside package configurations.
Security-conscious environments can immediately harden dependency policies by disabling non-registry installation sources entirely.
Even more significantly, npm CLI v12 plans to change the default behavior of –allow-git from permissive access to deny-by-default. This signals an industry-wide movement toward stricter dependency sourcing controls.
Rising Supply Chain Attacks Drive Defensive Changes
GitHub’s security investments arrive amid escalating attacks targeting open-source ecosystems.
One major example involved the Shai-Hulud campaign during 2025. Attackers leveraged compromised npm maintainer credentials obtained through phishing operations. Once inside developer environments, malicious code spread across widely used packages, stealing cloud credentials, scanning repositories using TruffleHog, and extracting secrets at scale.
Researchers also identified TeamPCP operations that poisoned popular packages through highly automated compromise chains designed to sustain long-term distribution.
More recently, the TrapDoor crypto-stealer campaign targeted dozens of packages distributed across npm, PyPI, and Crates.io ecosystems. Attackers increasingly exploit trusted software channels because developers naturally trust dependencies from established registries.
Traditional credential security measures alone no longer provide sufficient protection.
Security researchers have repeatedly advocated additional registry-level intelligence mechanisms, including:
Detecting unusual package publishing locations
Monitoring suspicious account behavior
Restricting lifecycle script modifications
Introducing anomaly detection systems
Limiting risky changes to major version updates
Staged publishing directly supports these goals by slowing malicious package propagation and introducing deliberate approval friction.
Immediate Mitigation Recommendations
Organizations managing npm infrastructure should prioritize several defensive measures immediately:
Upgrade to npm CLI 11.15.0 or newer
Replace npm publish workflows with npm stage publish
Implement OpenID Connect trusted publishing
Lock CI/CD systems to staging-only publishing methods
Configure dependency source restriction flags to none in hardened environments
Enable WebAuthn authentication instead of TOTP where possible
Review package publishing permissions regularly
Audit dependency sourcing policies across development pipelines
Modern software delivery increasingly depends on secure automation, but security architecture must evolve alongside attacker capabilities.
What Undercode Say:
GitHub’s latest npm protections represent a shift in software supply chain philosophy. For years, developer tooling prioritized speed and convenience above all else. Automated publishing pipelines became standard practice because they reduced deployment friction and accelerated software releases.
However, threat actors adapted quickly.
Compromised CI/CD systems became high-value targets because a single successful intrusion could silently poison thousands of downstream applications. Traditional security models assumed credential ownership implied authorization legitimacy. Modern attacks prove otherwise.
The “proof of presence” concept introduced by staged publishing is particularly important because it acknowledges an uncomfortable reality: automation alone cannot always distinguish legitimate behavior from malicious behavior.
An attacker with stolen tokens can imitate valid publishing workflows. They can operate inside CI/CD systems exactly as intended. Security mechanisms that depend entirely on identity validation become vulnerable when identity itself is compromised.
Human verification introduces friction intentionally.
Historically, security teams often viewed friction negatively because it slows productivity. But in supply chain defense, strategic friction can become a protective barrier.
The additional dependency restriction flags reveal another broader industry trend: reducing implicit trust.
Developers historically accepted dependencies from multiple locations without questioning sourcing integrity. Git repositories, remote tarballs, local paths, and external artifacts expanded flexibility but also widened attack surfaces.
Deny-by-default security architecture reverses this model.
Instead of trusting everything until blocked, systems trust nothing until explicitly allowed.
That transition aligns npm with zero-trust security principles increasingly adopted across enterprise infrastructure.
The future likely extends beyond staged publishing. Registry-level behavioral analytics, AI-driven anomaly detection, publishing reputation scoring, and stronger package provenance verification may become standard expectations.
Supply chain attacks remain attractive because attackers exploit trust itself.
Protecting modern software ecosystems increasingly requires validating not only code authenticity but also publication intent, infrastructure behavior, and dependency origin.
GitHub’s npm changes indicate software registries are beginning to recognize that trust alone no longer scales securely.
Developers should expect more security checkpoints, not fewer.
The organizations adapting early will likely experience fewer downstream compromises in the years ahead.
Fact Checker Results
✅ GitHub introduced staged publishing and expanded dependency source controls in npm CLI 11.15.0.
✅ Staged publishing requires maintainer verification using two-factor authentication before public package release.
❌ Credential security alone is not enough to stop modern software supply chain attacks, making layered defenses increasingly necessary.
Prediction
🔮 Software package registries will increasingly adopt approval checkpoints before public distribution.
🔮 Deny-by-default dependency policies will become standard security practice across development ecosystems.
🔮 Supply chain security controls will evolve beyond credentials toward behavioral validation and publishing anomaly detection.
▶️ Related Video (82% Match):
🕵️📝Let’s dive deep and fact‑check.
References:
Reported By: cyberpress.org
Extra Source Hub (Possible Sources for article):
https://www.instagram.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
