dependabot

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.

The case for a cooldown: Why Dependabot now waits before issuing version updates (opens in new tab)

Carlin is a GitHub Product Manager focused on GitHub Advanced Security and Dependabot. Her experience in software engineering and data science supports a data-driven approach to product management. ### Professional Background - Works on GitHub Advanced Security. - Focuses specifically on Dependabot. - Brings experience in software engineering and data science. ### Personal Interests - Lives in Washington with her partner and dog, Cookie. - Enjoys cycling and competitive board games. No technical blog post content was provided beyond this author biography.

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.