GitHub Adds Staged Publishing to npm to Prevent Supply Chain Attacks
Key Takeaways GitHub has introduced “staged publishing” and new install-time controls for the npm ecosystem. Staged publishing requires manual human approval for packages before they...
Key Takeaways
- GitHub has introduced “staged publishing” and new install-time controls for the npm ecosystem.
- Staged publishing requires manual human approval for packages before they become publicly installable, adding a critical security checkpoint.
- New install-time flags provide granular control over dependency sources, allowing developers to restrict installations from untrusted origins.
- These enhancements aim to significantly mitigate automated supply chain attacks and improve the overall security posture of npm packages.
- Organizations should update to npm CLI version 11.15.0 or later and integrate these features into their development workflows.
GitHub Enhances npm Security with Staged Publishing and New Install Controls
GitHub has rolled out substantial security enhancements for the npm ecosystem, introducing “staged publishing” and refined install-time controls. These new features are designed to significantly bolster defenses against automated supply chain attacks that frequently target open-source packages.
Table Of Content
Staged Publishing: A New Security Checkpoint
The core of the new security upgrade is the staged publishing feature, fundamentally altering how npm packages are released and distributed. Previously, a package would become immediately available upon publication. Now, a prebuilt package tarball is placed into a staging queue, requiring explicit human approval from a maintainer before it can be publicly installed.
This implementation introduces a vital security gate, particularly for automated CI/CD workflows, which are common targets for supply chain compromises. Even if an attacker manages to breach a pipeline or inject malicious code, the package cannot be released without this mandatory manual review.
Key security benefits of staged publishing include:
- Enforcement of human approval, further secured with two-factor authentication (2FA).
- Clear visibility of staged packages through both the npm CLI and npmjs.com interface.
- Robust protection against unauthorized or automated publishing attempts.
- Reinforced proof-of-presence for maintainers during the release process.
Developers can access this feature starting with npm CLI version 11.15.0. It requires a shift from the traditional npm publish command to npm stage publish for workflows utilizing this new security layer. GitHub strongly advocates for combining staged publishing with trusted publishing via OpenID Connect (OIDC). This integration enables CI/CD systems to publish packages directly into the staging queue without exposing long-lived credentials, minimizing the risk of credential theft and automated malicious releases.
Organizations can also enforce policies that mandate stage-only publishing, ensuring that direct npm publish commands are rejected, only npm stage publish is permitted from CI pipelines, and final approval is always completed by a maintainer on a trusted device.
Granular Install-Time Controls
In addition to staged publishing, npm 11.15.0 introduces new install-time security flags, offering granular control over the origins from which dependencies can be installed. These flags are crucial for preventing the inclusion of malicious or unexpected packages from untrusted sources.
The new flags include:
--allow-file: Manages installations originating from local files or tarballs.--allow-remote: Restricts dependencies fetched from remote URLs.--allow-directory: Governs installations from local directories.--allow-git(an existing flag): Controls installations from Git repositories.
Each flag supports two modes: all (the default) or none, and can be configured through .npmrc or package.json. These controls empower developers to implement stringent allowlist policies, significantly reducing the attack surface from non-registry sources often exploited in dependency confusion or injection attacks.
Security Impact and Recommendations
GitHub has also confirmed that npm CLI version 12 will see a change in the default behavior for --allow-git, shifting from all to none. This signals a clear move towards stricter default security settings across the npm ecosystem. Developers are encouraged to proactively adopt these restrictions by configuring the new flags manually.
For instance, an organization can configure its environment to block all non-registry installations by setting --allow-remote=none, --allow-file=none, and --allow-directory=none, thereby allowing only trusted registry packages. When combined with staged publishing, these measures create a highly controlled pipeline where both the creation and consumption of packages are tightly secured.
These updates directly address prevalent supply chain attack vectors, including malicious code injection within CI/CD pipelines, dependency confusion via external sources, and unauthorized package publishing. By integrating human validation and stricter dependency controls, GitHub is steering npm towards a more robust, zero-trust supply chain model.
What You Should Do
- Upgrade npm CLI: Immediately update to npm CLI version 11.15.0 or later to access these new security features.
- Implement Staged Publishing: Integrate
npm stage publishinto your CI/CD workflows and enforce human approval for package releases, ideally with 2FA. - Configure Install-Time Controls: Utilize the new
--allow-file,--allow-remote, and--allow-directoryflags to restrict dependency installations from untrusted sources. Consider setting these tononeby default and creating explicit allowlists. - Combine with Trusted Publishing: Leverage OpenID Connect (OIDC) with staged publishing to enhance security for automated CI/CD systems without exposing long-lived credentials.
- Review Policies: Update organizational policies to mandate the use of staged publishing and strict dependency source controls.
Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.



No Comment! Be the first one.