Strengthening supply chain security: Preparing for the next malware campaign

Source: GitHub Blog

Overview

The open‑source ecosystem continues to face organized, adaptive supply‑chain threats that spread through compromised credentials and malicious package‑lifecycle scripts. The most recent example is the multi‑wave Shai‑Hulud campaign.

What We’re Seeing

• Rapid learning: Adversaries quickly adapt their tactics.
• Targeted maintainer workflows: Attackers focus on the human and process elements of package maintenance.
• Trust‑boundary exploitation: Publication pipelines are leveraged to inject malicious code.

Durable Lessons

1. Assume breach: Treat every credential as potentially compromised.
2. Secure the pipeline: Enforce strict controls on who can publish and what scripts can run.
3. Monitor for anomalies: Look for unusual activity in CI/CD, publishing, and credential usage.

Actionable Recommendations

• Rotate credentials regularly and store them in a secrets manager.
• Enable two‑factor authentication (2FA) for all maintainer accounts.
• Restrict write access to only those who need it; use least‑privilege principles.
• Audit package‑lifecycle scripts before they are merged or executed.
• Implement supply‑chain scanning tools that detect malicious code patterns.
• Set up alerts for sudden spikes in package downloads or publishing frequency.

Looking Ahead

We’ll be expanding the npm security roadmap over the next two quarters with:

• Enhanced credential‑leak detection mechanisms.
• New policy‑as‑code features for automated enforcement of security rules.
• Improved visibility into dependency provenance and integrity checks.

This post distills durable lessons and actions to help maintainers and organizations harden their systems and prepare for the next campaign—not just respond to the last one.

Recent Shai‑Hulud Campaigns

Shai‑Hulud is a coordinated, multi‑wave campaign targeting the JavaScript supply chain. It has evolved from opportunistic compromises to engineered, targeted attacks.

Wave 1 – Compromised Maintainer Accounts

• Injected malicious post‑install scripts into packages.
• Goals: slip malicious code into dependencies, exfiltrate secrets, and self‑replicate.
• Demonstrated how a single foothold can ripple across the ecosystem.

Wave 2 – Shai‑Hulud 2.0

• Self‑replication upgraded to enable cross‑victim credential exposure.
• Added endpoint command‑and‑control via self‑hosted runner registration.
• Harvested a broader set of secrets to fuel further propagation and introduced destructive functionality.
• Focus shifted to CI environments:
  • Detects when it runs inside a CI pipeline.
  • Deploys privilege‑escalation techniques targeting specific build agents.
• Utilized a multi‑stage payload that is harder to detect than the first‑wave payload.
• The shortened timeline between variants signals an organized adversary that studies community defenses and iterates rapidly.

Common Characteristics Across Waves

• Credential‑adjacent compromise

  • Initial foothold via compromised credentials or OAuth tokens.
  • Pivot to collect additional secrets (npm tokens, CI tokens, cloud credentials).
  • Enables reuse across organizations and future waves without a single point of failure.

• Install‑time execution with obfuscation

  • Malicious post‑install or lifecycle scripts injected into packages (or dependency chains).
  • Payloads activate conditionally (e.g., environment checks, organization scopes).
  • Exfiltration techniques are tailored to the runtime environment.

• Targeting trusted namespaces and internal package names

  • Affected popular, trusted packages.
  • Infected packages were published under existing names.
  • Wave 2 patched version numbers to appear as legitimate updates, blending with normal maintainer activity.

• Rapid iteration and engineering around defenses

  • Short intervals between variants.
  • Deliberate changes to bypass previous mitigations.
  • Goal: durable access and scalable spread, not one‑off opportunism.

• Review blind spots in publication pipelines

  • Discrepancies between source and published artifacts.
  • Lifecycle scripts and build‑time transformations create gaps.
  • Without artifact validation or staged approvals, injected behavior can slip through unnoticed.

Takeaway

Recent waves reinforce that defenders must harden publication models and credential flows proactively, rather than tailoring mitigations to any single variant. Continuous validation of artifacts, strict CI pipeline controls, and vigilant credential management are essential to disrupt the Shai‑Hulud supply‑chain threat.

What’s Next for npm

We’re accelerating our security roadmap to address the evolving threat landscape. Moving forward, our immediate focus is on adding support for:

• Bulk OIDC onboarding – Streamlined tooling to help organizations migrate hundreds of packages to trusted publishing at scale.
• Expanded OIDC provider support – Adding support for additional CI providers beyond GitHub Actions and GitLab.
• Staged publishing – A new publication model that gives maintainers a review period before packages go live, with MFA‑verified approval from package owners. This empowers teams to catch unintended changes before they reach downstream users—a capability the community has been requesting for years.

Together, these investments give maintainers stronger, more flexible tools to secure their packages at every stage of the publication process.

Advice for GitHub and npm Users and Maintainers

Malware such as Shai‑Hulud often spreads by injecting malicious code into npm packages. The code runs during installation, compromising any user who installs the package. Because npm packages typically have many dependencies, compromising a single package can indirectly affect many others. Attackers may also hoard harvested tokens and launch new campaigns weeks or months later.

Below is a concise summary of our top recommendations. For deeper analysis and additional guidance, see the “References” section that follows.

Advice for Everyone

• Enable phishing‑resistant MFA on all accounts, especially for package managers such as

  • GitHub
  • npm
  • PyPI
  • RubyGems
  • NuGet

• Set token expiration dates and rotate them regularly. Organizations can enforce a maximum‑lifetime policy.

• Audit and revoke access for unused GitHub/OAuth apps.

• Develop in a sandbox (e.g., GitHub Codespaces, a VM, or a container) to limit the impact of any accidentally executed malware.

Advice for Maintainers

• Enable branch protection to prevent direct pushes to the main branch, even if an attacker obtains a valid token.

• Use trusted publishing instead of long‑lived tokens. Trusted publishing is available for:

  • npm
  • PyPI
  • RubyGems
  • NuGet

• Pin CI dependencies, enable code scanning, and promptly resolve any alerts:

  • Pinning:
  • Code scanning:
  • Resolving alerts:

• Validate published artifacts (e.g., using Subresource Integrity or artifact build attestations) to ensure the distributed tarballs/bundles match the source:

  • SRI:
  • Artifact attestations:

If you suspect a compromise, contact GitHub Support for assistance.

References

• Report a malicious package in npm
• Our plan for a more secure npm supply chain
• Strengthening npm security
• View malware advisories in the Advisory Database
• Quickstart for securing your repository
• Dependency review on GitHub
• OpenSSF best practices for npm
• Microsoft’s guidance for detecting and defending
• Recent improvements to GitHub Actions

Written by

Madison Oliver is a vulnerability‑transparency advocate and senior security manager at GitHub, leading the Advisory Database curation team. She is passionate about vulnerability reporting, response, and disclosure, and co‑chairs the relevant Open Source Security Foundation (OpenSSF) working group and serves on the CVE Program Board. Her views are enriched by prior experience as a product incident‑response analyst at GitHub and as a vulnerability coordinator at the CERT Coordination Center, Software Engineering Institute, Carnegie Mellon University.

Related posts

(none listed)

Explore more from GitHub