supply-chain-security

How we took malware advisories beyond npm (opens in new tab)

Ankit is a Senior Engineering Manager at GitHub and leads the Dependabot team within the Supply Chain Security organization. His work involves protecting more than 30 million repositories across over 34 package ecosystems, giving him extensive exposure to software supply-chain risks and attacks. ## Role and Responsibilities - Leads the Dependabot team at GitHub. - Works within GitHub’s Supply Chain Security organization. - Oversees systems monitoring 30M+ repositories. - Supports more than 34 package ecosystems. ## Security Perspective - The scale of Dependabot’s coverage exposes Ankit to a wide range of supply-chain threats. - This responsibility has made him particularly vigilant about software supply-chain attacks.

Tame Dependabot: Group your updates, slow the cadence, keep security fast (opens in new tab)

Dependabot can generate unnecessary noise when it opens a separate pull request for every dependency update, especially on active repositories. Using dependency groups, a slower schedule, and coverage for all relevant ecosystems turns that stream into predictable maintenance batches. The recommended approach preserves the speed of security updates while reducing routine review and CI overhead. ## The Problem: Frequent, Un grouped Updates - Microsoft’s GCToolkit had 92 Dependabot commits out of 578—about one in six—with 61 arriving in the previous year. - Its original configuration: - Checked GitHub Actions dependencies daily. - Opened a separate pull request for every dependency. - Limited open Dependabot pull requests to 10. - The pull-request limit capped the visible backlog but did not reduce the underlying noise. ## Grouping Dependencies into Batches - Dependabot’s `groups` configuration combines multiple updates into one pull request. - A wildcard pattern such as `"*"` includes all dependencies in that ecosystem. - Instead of 10 pull requests and 10 CI runs, maintainers receive one reviewable batch. - Larger projects can define separate groups for categories such as testing and production dependencies. - In monorepos, Dependabot can group the same dependency across multiple directories using `directories` and `group-by: dependency-name`. ## Moving from Daily to Monthly Updates - Changing `schedule.interval` from `daily` to `monthly` creates a predictable maintenance cycle. - Combined with grouping, this produces one batch per ecosystem each month rather than a continuous stream. - `weekly` is an alternative for projects needing a faster cadence. - Specific days and times can be configured with `schedule.day` and `schedule.time`. ## Covering All Dependency Ecosystems - The original configuration monitored only GitHub Actions. - The revised configuration also monitors Maven, which is essential for a Java project like GCToolkit. - Each ecosystem receives its own schedule and grouped pull request, keeping Actions and Maven updates separate and manageable. ## Keeping Security Updates Fast - The grouping and scheduling changes primarily affect routine version updates, not Dependabot security fixes. - Maintainers can therefore slow ordinary dependency maintenance without delaying urgent vulnerability patches. A practical configuration is to group all routine updates by ecosystem, run them monthly—or weekly when appropriate—and explicitly configure every package ecosystem used by the repository. This reduces maintenance noise while keeping security response timely.

Disrupting supply chain attacks on npm and GitHub Actions (opens in new tab)

GitHub describes a layered approach to disrupting npm and GitHub Actions supply-chain attacks, which typically compromise one project, steal credentials, and spread malware across many others. Rather than relying on one defensive feature, GitHub is targeting several links in the attack chain—from initial compromise through credential theft and malicious publishing. Recent protections add account recovery delays, safer workflow defaults, credentialless publishing, network monitoring, and stronger publishing approvals. ## Anatomy of Supply-Chain Attacks - Attacks commonly: - Compromise a maintainer account or CI/CD workflow. - Escalate access by stealing credentials. - Use those credentials to infect additional packages and projects. - GitHub says effective defense requires multiple mitigations that disrupt the most damaging steps in the chain. ## Preventing Initial Compromise - **High-impact npm account protection** - Accounts enter read-only mode for 72 hours after an email change or use of a 2FA recovery code. - The delay gives maintainers time to detect phishing-related account takeover and recover access. - **Safer `pull_request_target` checkout defaults** - `actions/checkout` now prevents commonly exploited workflows from checking out untrusted code from forks by default. - This reduces exposure to “pwn requests,” where fork-provided code executes with workflow privileges. - **Workflow execution policies** - Enterprise, organization, and repository administrators can control who may trigger workflows and which trigger types are permitted. - These policies provide configurable least-privilege controls for Actions. - **Read-only Actions cache for untrusted triggers** - Less-trusted workflows can no longer modify caches shared with more privileged workflows. - This blocks cache poisoning attacks intended to escalate access to release and publishing credentials. ## Limiting Credential Exfiltration - **npm trusted publishing for CircleCI** - CircleCI can now use trusted publishing, allowing packages to be published without long-lived credentials stored in CI/CD. - Removing persistent tokens reduces the value of compromised workflows. - **Actions network firewall** - The technical preview logs outbound network traffic from workflow runs. - This can expose suspicious downloads or credential exfiltration to unfamiliar domains. - Planned restrictions will allow organizations to block unauthorized network destinations. ## Slowing Attack Propagation - **Staged npm publishing** - Publishing credentials alone are insufficient to immediately release a new package version. - Packages remain staged until an additional approval and 2FA authentication occur through npm’s CLI or website. - This opt-in control separates automated publishing credentials from final authorization, giving maintainers a chance to detect malicious releases. Together, these measures reduce the opportunities for attackers to enter projects, obtain powerful credentials, and rapidly publish malware. GitHub’s recommendation is effectively to combine safer workflow configuration, short-lived or trusted authentication, network visibility, and additional publishing approval rather than depending on any single control.

Shai-Hulud copycat campaign targets Python developers through PyPI typosquatting (opens in new tab)

GitLab researchers uncovered a coordinated PyPI supply-chain campaign distributing a copy of the Shai-Hulud worm. Five packages—four typosquats and one compromised legitimate project—execute malware during Python startup, steal credentials from CI/CD and cloud environments, and propagate through developers’ repositories and package registries. The campaign demonstrates that Python packages can be weaponized without imports or explicit function calls. ## Malicious PyPI Packages - All packages were published by the `elitexp` account: - `rlask` and `tlask`, typosquats of Flask - `rsquests`, a typosquat of Requests - `nhmpy`, a typosquat of NumPy - `mflux-streamlit`, a legitimate project later weaponized in versions `0.0.3` and `0.0.4` - The attacker first uploaded clean probe versions matching current upstream version numbers, then replaced them with payload-bearing releases. - The activity followed the public release of Shai-Hulud’s source code, suggesting an independent copycat operation targeting Python users. ## Python Startup-Based Infection - The malware uses Python `.pth` files, which Python processes automatically at startup. - The dropper: - Checks for a `.bun_ran` marker in the temporary directory. - Downloads the Bun JavaScript runtime from GitHub. - Executes a roughly 5 MB obfuscated JavaScript payload. - Early `rlask` versions also included `sitecustomize.py`, which searched `sys.path` for and executed a hidden `_index.js` file. - This approach requires no explicit package import or function invocation. ## Payload Obfuscation - The JavaScript is protected by multiple layers: - Package-specific ROT-N encoding - AES-128-GCM encryption - Variable-name mangling using `_0x` identifiers - Researchers identified: - A small encrypted Bun downloader - A 772 KB Shai-Hulud credential stealer - Approximately 2,538 hardcoded strings ## Credential Theft The worm targets credentials and secrets from: - GitHub Actions tokens, repository secrets, OIDC tokens, artifacts, and runner memory - AWS IAM credentials, instance metadata, Secrets Manager, SSM, and STS tokens - Azure managed identities, Key Vault, and Microsoft Graph tokens - GCP service-account keys and application credentials - HashiCorp Vault tokens and Kubernetes authentication - npm, JFrog, PyPI, and RubyGems publishing credentials - SSH private keys and Kubernetes service-account tokens - Sigstore credentials and Fulcio signing certificates - MongoDB, MySQL, PostgreSQL, and Redis connection strings ## Self-Propagation Using stolen credentials, the worm can: - Add `.github/setup.js` and workflow files to repositories so it runs in other CI pipelines. - Insert `.github/copilot-instructions.md` to influence AI coding assistants. - Publish poisoned packages to PyPI, npm, and RubyGems. - Attempt privilege escalation on self-hosted runners through `sudoers` modifications. - Detect StepSecurity’s harden-runner and alter its behavior. ## Attacker Infrastructure and Weaponized Project - The PyPI account was created in 2024 and was associated with the legitimate `mflux-streamlit` project. - Package uploads used `Bun/1.3.14`, matching the runtime downloaded by the malware. - Unlike a pure typosquatting campaign, the compromise of a real project could affect existing users through normal dependency updates. Developers should audit environments for the affected packages, review CI/CD and cloud credentials, rotate exposed secrets, and enforce dependency pinning and package provenance checks. CI runners and publishing tokens should be treated as potentially compromised if any affected version was installed.

Securing the open source supply chain across GitHub (opens in new tab)

Attackers increasingly target GitHub Actions workflows to steal secrets, publish malicious packages, and spread into additional projects. GitHub recommends reducing credential exposure, hardening workflows, and using automated tools such as CodeQL and Dependabot. It is also expanding trusted publishing, malware detection, and GitHub Actions security improvements in response to campaigns such as Shai-Hulud. ## How attacks begin - Many supply-chain attacks start by exploiting insecure GitHub Actions workflows. - Stolen API keys and other secrets can let attackers publish packages from their own machines. - Malicious packages can then compromise downstream projects and propagate the attack. ## Securing GitHub Actions today - Enable CodeQL’s GitHub Actions queries, which are free for public repositories, to identify workflow security weaknesses. - Avoid triggering workflows with `pull_request_target`. - Pin third-party Actions to full-length commit SHAs. - Updates should be made by maintainers or Dependabot. - Treat pull requests that change pinned Actions with suspicion. - Protect workflows against script injection when using pull-request or other user-submitted content. - Monitor GitHub’s Advisory Database and use Dependabot malware alerts to detect compromised or vulnerable dependencies. ## Replacing secrets with trusted publishing - GitHub recommends using short-lived OpenID Connect tokens containing a workflow’s workload identity instead of storing long-lived secrets. - Cloud providers, package registries, and hosted services can use these tokens to authorize workflow activity. - Through collaboration with OpenSSF, trusted publishing is supported by npm, PyPI, NuGet, RubyGems, Crates, and other registries. - Trusted publishing both removes credentials from build pipelines and provides a signal when a package unexpectedly switches away from it. ## Detecting malicious packages - npm publishes more than 30,000 packages daily and scans every package version for malware. - Hundreds of newly published packages contain malicious code each day. - Human review confirms detections before action is taken, helping avoid disrupting legitimate maintainers. - Even a 1% false-positive rate would affect hundreds of valid package releases daily at npm’s scale. ## GitHub’s upcoming security work - Attacks such as Shai-Hulud accelerated npm’s security roadmap. - GitHub is expanding trusted publishing, malware detection and removal, and collaboration with maintainers. - The company is also revisiting and accelerating its GitHub Actions security roadmap. - New protections may require workflow changes or create compatibility concerns, so GitHub aims to make the transition gradual and solicits community feedback. Projects should audit their Actions workflows immediately, eliminate long-lived publishing credentials where possible, pin dependencies, and enable CodeQL and Dependabot. Adopting trusted publishing provides both stronger protection and useful evidence for identifying suspicious package releases.