Listen to this Post
Introduction
The software supply chain has become a prime target for attackers, with npm packages acting as a primary vector for malware distribution through automatic execution of lifecycle scripts like preinstall, install, and postinstall. In response to escalating threats, a series of coordinated security enhancements across npm, GitHub, and VS Code have been implemented between 2025 and 2026, fundamentally altering how packages are published, trusted, and installed. This article explores these changes, their potential impact on supply chain security, and the new responsibilities they place on developers and organizations.
Learning Objectives
- Understand the key security changes in npm, GitHub, and VS Code, including their benefits and limitations.
- Configure and implement security controls such as OIDC trusted publishing, staged publishing, dependency cooldowns, and Dependabot malware alerts.
- Analyze the residual risks and develop a defense-in-depth strategy to protect against evolving supply chain attacks.
You Should Know
1. OIDC Trusted Publishing: Eliminating Long-Lived Tokens
The traditional method of using a `NPM_TOKEN` stored in GitHub secrets posed a significant risk, as these long-lived tokens could be stolen and used to publish malicious packages years later. npm addressed this by introducing OpenID Connect (OIDC) trusted publishing in July 2025, which eliminates the need for long-lived tokens altogether. Instead, GitHub Actions can request a short-lived OIDC token to authenticate with npm, a process that is both secure and auditable.
Step-by-step guide to configure OIDC trusted publishing:
- Create a package on npm: Trusted publishing requires an existing package. If you haven’t published yet, publish a placeholder version first.
-
Configure the trusted publisher on npmjs.com: Navigate to your package’s settings and add a new trusted publisher. Select your CI/CD provider (e.g., GitHub Actions). You will need to provide your GitHub organization, repository name, and the specific workflow filename, and optionally restrict to a particular branch.
Bulk configuration is also available for multiple packages npm trust add --owner my-github-org --repo my-repo --workflow .github/workflows/publish.yml
-
Update your GitHub Actions workflow: Remove any reference to `NPM_TOKEN` secrets and add the necessary `id-token: write` permission.
name: Publish Package to npm on: push: branches: [ main ] permissions: id-token: write Required for OIDC contents: read jobs: publish: runs-on: ubuntu-latest steps:</p></li> </ol> <p>- uses: actions/checkout@v4 - uses: actions/setup-1ode@v4 with: node-version: '20.x' registry-url: 'https://registry.npmjs.org' - run: npm ci - run: npm test - run: npm publish --provenance
The `–provenance` flag generates a public attestation linking the package back to the exact GitHub Actions workflow run.
2. Staged Publishing: 2FA-Gated Human Approval
While OIDC prevents token theft, a compromised CI/CD workflow could still publish a malicious package. Staged publishing, which became generally available in May 2026, adds a crucial human-in-the-loop control. An automated workflow can only “stage” a new version; a human maintainer must then approve it using a second factor of authentication (2FA) before it goes live. This prevents a compromised CI pipeline from instantly distributing malware.
Step-by-step guide to using staged publishing:
- Enable staged publishing in your package settings: On npmjs.com, navigate to your package’s settings and enable “Staged Publishing”. Note that the account approving the staged package must have 2FA enabled.
-
Stage a new version from your CI/CD pipeline: In your workflow, replace `npm publish` with
npm stage publish.This command will not prompt for 2FA in a CI environment npm stage publish
The output will provide a stage request ID for tracking.
-
Approve or reject the staged package: A maintainer can then approve the staged package via the command line or the npm website. Both methods require 2FA.
List all pending stage requests npm stage ls Approve a specific staged version using its ID npm stage approve <id> Reject a staged version npm stage reject <id>
On the npm website, you can find staged versions under the “Staged Packages” tab and click “Approve”.
-
Cooldowns and Minimum Release Age: The Cheapest High-Value Control
A compromised package version is often detected and pulled within hours of its release. A cooldown, or “minimum release age,” is a simple yet highly effective control that prevents npm from installing any package version until it has been publicly available for a set number of days. This gives the security community time to identify and report malware before it can be widely distributed.
Step-by-step guide to configuring cooldowns:
| Package Manager | Configuration Command (per project) | Purpose |
|:|:|:|
| npm | `npm config set min-release-age 7` | Refuse to install versions published in the last 7 days. |
| pnpm | `pnpm config set minimumReleaseAge 7` | Same functionality, available since v10.16 (Sept 2025). |
| yarn | `yarn config set npmMinimalAgeGate 7` | Same functionality, available since v4.10.0 (Sept 2025). |
| bun | `bun config set minReleaseAge 7` | Same functionality, available since v1.3. |A proposal exists to make a 7-day cooldown the default setting for all major package managers.
- VS Code Marketplace Cooldown: Protecting Against Malicious Extensions
In June 2026, Microsoft introduced a 2-hour cooldown for automatic updates of third-party VS Code extensions. When automatic updates are enabled, a new extension version will only be installed two hours after its publication. This acts as a quarantine period, giving Microsoft and the community time to identify and remove malicious extensions before they are automatically pushed to millions of developers.
How to manage extension security in VS Code:
- Check your VS Code version: This feature is active from version 1.123 onwards.
- Important Limitation: This cooldown period does not apply to extensions from trusted publishers like Microsoft, GitHub, and OpenAI, which continue to update immediately.
- Review installed extensions: Regularly audit your installed extensions and remove any that are unused or from untrusted publishers.
List all installed extensions with their versions code --list-extensions --show-versions
5. Dependabot Malware Alerting: Opt-In but Limited
GitHub’s Dependabot can now alert you when your repository depends on an npm package version that has a known malware advisory (GHSA). This feature, which returned in March 2026, is designed to provide malware visibility without the noise of standard CVE alerts.
Step-by-step guide to enable Dependabot malware alerts:
- Navigate to your repository or organization on GitHub.
- Go to Settings → Code security → Dependabot.
- Under the “Dependabot alerts” section, enable the “Malware alerts” toggle.
- Once enabled, Dependabot will scan your `package-lock.json` and `npm-shrinkwrap.json` files for known malicious versions.
Key Limitations:
- Opt-in: The feature must be explicitly enabled and is not on by default.
- Reactive: It only blocks versions that already have a published advisory, which can take hours or days to be created after a novel malware campaign is released.
- Ecosystem-specific: Initially only covers npm, even though malware on PyPI is growing at a similar rate.
- Alert fatigue: Many developers ignore Dependabot alerts because they are often noisy or difficult to triage.
- NPM Lifecycle Scripts: Off by Default in v12
Beginning with npm v12, scheduled for July 2026, lifecycle scripts (preinstall,install,postinstall) from dependencies will no longer run automatically. This closes the primary mechanism through which malicious packages have executed code on developer machines for over a decade. Instead, you must explicitly opt-in to allow scripts for specific packages.
Step-by-step guide to managing the new script controls:
- Prepare your projects before the v12 upgrade: npm 11.16.0+ includes the new features in a “warnings only” mode. Update npm globally.
npm install -g npm@11
-
Run an installation to see what will break: Running `npm install` on an existing project will now show warnings for packages with pending scripts.
npm install
You will see a list of packages that rely on install scripts.
-
Use `npm approve-scripts` to create an allowlist: This command will review the packages with pending scripts. You can choose to approve them all, approve specific ones, or deny them.
Discover which packages have pending scripts npm approve-scripts --allow-scripts-pending Approve a specific package's scripts npm approve-scripts sharp esbuild Deny scripts for a package (will cause it to fail if it needs them) npm deny-scripts bcrypt
-
Handle non-registry dependencies: Git and remote HTTPS dependencies will no longer run scripts unless you explicitly allow them.
Install a git dependency without allowing its scripts (default in v12) npm install git+https://github.com/example/repo.git Allow scripts for a specific git dependency npm install git+https://github.com/example/repo.git --allow-git=example/repo
7. Defense-in-Depth: Beyond the Registry
No single control is sufficient. A layered defense strategy is essential. This includes using package firewalls and thoroughly understanding your dependency tree.
Implementing a multi-layered defense:
- Use a package firewall: Tools like `npq` (Node Package Quarantine) wrap your package manager and check packages against security databases before installation.
Install npq globally npm install -g npq Use npq to safely install a package npq install some-package
Other enterprise-grade firewalls in this space include Socket, Aikido, and Endor Labs.
-
Inventory your dependencies: Understand not just your direct dependencies, but every transitive package and what it is allowed to do.
List the entire dependency tree npm ls --depth=10 Output dependencies in JSON format for analysis npm ls --json > dependencies.json
- Automate dependency auditing: Integrate `npm audit` into your CI/CD pipelines.
npm audit --audit-level=critical
What Undercode Say:
- Key Takeaway 1: npm’s shift to deny-by-default for install scripts is the single most important change they could make to disrupt malware delivery, but its long-term effectiveness is contingent on developers resisting click-through fatigue and maintaining a curated allowlist.
- Key Takeaway 2: The introduction of OIDC, staged publishing, and cooldowns represents a positive, fundamental restructuring of trust and control, but they are all reactive or administrative solutions that do not address the root cause: the registry’s own lack of proactive, adequate scanning.
Analysis: The security improvements across npm, GitHub, and VS Code are a landmark shift in supply chain security, turning many decade-old dangerous defaults into deliberate actions. However, these measures are not a silver bullet and risk creating a “security theatre” effect. As the analysis on OpenSourceMalware argues, when legitimate functionality is forced off the well-lit path, it adopts behaviors that look identical to malware evasion, making the defender’s signal-to-1oise ratio worse. Furthermore, the core problem persists: a registry that profits from being the default continues to under-invest in its own scanning, pushing the burden of detection and response onto developers and third-party vendors. Ultimately, these controls move the malware around, but only a well-resourced and diligent team that truly knows its dependencies can make the problem matter less.
Prediction:
- -1: Attack Adaptation is Inevitable. Attackers will rapidly adapt to these new defaults. Malicious activities will relocate from npm lifecycle scripts to other developer surfaces that are less instrumented, such as rogue `curl | bash` commands in `README.md` files, malicious VS Code tasks, or post-install binaries downloaded from external CDNs.
- -1: Defenders Face a New Signal Crisis. The convergence of legitimate and malicious installation patterns will create a severe signal-to-1oise problem. Security teams will find themselves drowning in alerts and suspicious-looking packages, many of which are benign, making it significantly harder to spot the truly dangerous needles in a much larger haystack.
- +1: Reduced Scale of Instant Attacks. Despite the limitations, these controls will successfully reduce the scale and speed of mass supply chain attacks. The combined effect of cooldowns and staged publishing will ensure that the “typhoid Mary” scenario—where a single compromised package spreads to millions of developers within minutes—becomes a thing of the past.
- +1: Forced Deliberation. By making core security functions like allowing scripts and approving publications explicit, these changes force developers to be more deliberate and mindful of their actions. This cultural shift, if embraced, could lead to a more security-conscious development lifecycle overall.
▶️ Related Video (72% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by ThousandsIT/Security Reporter URL:
Reported By: With The – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeTesting & Stay Tuned:
