Skip to content

dependabot

Subscribe to all “dependabot” posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

~ cd github-changelog
~/github-changelog|main git log main
showing all changes successfully

For enterprise owners and security managers dedicated to managing security products, we are excited to announce a new capability: you can now gain historical insights into security products enablement trends across your GitHub enterprise. This overview helps you understand how security product coverage is being implemented across your company.

Following our March announcement of the public beta of the enablement trends report for organizations, which allowed monitoring of enablement trends for all security products within your GitHub organization, we’ve expanded this capability to the enterprise level. The addition of an owner filter further simplifies the navigation of metrics for repositories owned by specific organizations.

Enterprise enablement trends report

Explore enablement trends and gain historical insights into the activation status of GitHub security features:
* Dependabot alerts
* Dependabot security updates
* Code scanning
* Secret scanning alerts
* Secret scanning push protection

Historical data is available from January 1, 2024, with the exception of Dependabot security updates data, which is available from January 17, 2024.

To access the enablement trends report, navigate to your enterprise account. In the enterprise account sidebar, click Code Security.

This feature is now available as a public beta on GitHub Enterprise Cloud and will be available in GitHub Enterprise Server 3.14.

Learn more about security overview and join the discussion within the GitHub Community

See more

Starting today, developers using GitHub Enterprise Cloud (GHEC) and Free, Pro, and Teams accounts can enable their repositories and/or organizations to run Dependabot updates as an Actions workflow. With this change, the job that Dependabot runs to generate pull requests will run in GitHub Actions. This is the start of an effort to consolidate Dependabot’s compute platform to Actions, with further migration plans to be announced later.

Who can opt-in?

GHEC, Free, Pro, and Teams administrator users can enable Dependabot on Actions today.

What if I’m on Enterprise Server (GHES)?

GitHub Enterprise Server (GHES) and Proxima users already run Dependabot on Actions; no further steps are required to enable Dependabot on Actions for these users.

Why choose to run Dependabot as an Actions workflow today?

Enabling Dependabot on Actions will yield performance benefits like faster Dependabot runs and increased visibility into errors to manually detect and troubleshoot failed runs. Actions APIs and webhooks will also be able to detect failed runs and perform downstream processing should developers wish to configure this in their CI/CD pipelines. There will be no change or impact to the Dependabot functionality, and there will be no impact to billed Actions minutes (i.e. Dependabot runs are free).

Will this count towards Actions minutes or costs?

This does not count towards GitHub Actions minutes – meaning that using Dependabot continues to be free for everyone. Beginning today, using Dependabot as an Actions workflow is free for everyone and generally available on all repositories.

What’s the next migration phase for Dependabot on Actions?

Over the course of the next year, we are migrating all Dependabot workflows to run on Actions compute infrastructure. You can opt-in today to gain access to these benefits, but they’ll be coming soon to all repos without needing to opt-in as well. We’re excited for faster runs, increased troubleshooting visibility, and other future benefits running Dependabot on Actions will unlock. We’ll be in close contact with those organizations who own repositories with Actions disabled and Dependabot enabled as we kick off the compute infrastructure migration. If you have questions or concerns, please contribute to our community discusson or contact our support team.

How to enable Dependabot on Actions?

GHEC, Free, Pro, and Teams administrator users can enable Dependabot on Actions runners at either the repository or organization level from the Code security and analysis settings pages. For more information, see our documentation on enabling Dependabot on Actions runners.

When will self-hosted runners, larger runners, and actions runner controller (ARC) be supported?

May 2024

When will VNETs be supported?

This work is still in progress; we don’t yet have an estimated date when these will be available.

Can I use Actions workflows and APIs to trigger Dependabot jobs?

Today, Dependabot jobs can only be triggered from the Dependabot UI, and not by Actions workflows or APIs.

If I see a Dependabot job fail in Actions, how can I restart it?

Check out our documentation on re-running a verison updates job or re-running a security updates job.

If I enable Dependabot on Actions, can I later opt-out?

At this time, you can opt out of enabling Dependabot on Actions. However, this ability will change within the next year as we consolidate Dependabot’s compute platform to Actions.

What if I don’t want to turn on Actions for my repository or organization? What happens if Actions is disabled in a repository but Dependabot is enabled to run on Actions?

During this opt-in phase of the compute infrastructure migration, if you enable Dependabot on Actions but disable Actions at the repository or organization level, Dependabot will run on the legacy compute infrastructure. Please enable Actions either in your Dependabot-enabled repository or across your organization if you wish to opt in to run Dependabot on Actions.

Read more about Dependabot on GitHub Actions runners.

Join the discussion within GitHub Community.

See more

Today, we’re releasing security tool-specific filters for the security overview dashboard and secret scanning metrics page.

Security tool-centric filters in the filter bar drop-down on the overview dashboard

Have you ever wondered, “How well is my organization handling SQL injections?” or “How quickly are we responding to [partner name] secret leaks?” Maybe you’re curious about the pace of updating your npm dependencies. Well, wonder no more!

With our new security tool filters, you can tailor your search to the exact details you’re curious about, giving you a more focused and relevant report for your needs.

Discover the new filters that are designed to transform your security analysis:

  • Dependabot filters: Zero in on a specific ecosystem, package, and dependency scope.
  • CodeQL/third-party filters: Drill down to the rule that matters most to you.
  • Secret scanning filters: Get granular with filters for secret type, provider, push protection bypassed status and validity.

These features are now available as a public beta on GitHub Enterprise Cloud and will be available in GitHub Enterprise Server 3.14.

Learn more about security overview and send us your feedback

See more

Code security configurations simplify the rollout of GitHub security products at scale by defining collections of security settings that can be applied to groups of repositories. Your organization can apply the ‘GitHub recommended’ security configuration, which applies GitHub’s suggested settings for Dependabot, secret scanning, and code scanning. Alternatively, you can instead create your own custom security configurations. For example, an organization could create a ‘High risk’ security configuration for production repositories, and a ‘Minimum protection’ security configuration for internal repositories. This lets you manage security settings based on different risk profiles and security needs. Your organization can also set a default security configuration which is automatically applied to new repositories, avoiding any gaps in your coverage.

With security configurations, you can also see the additional number of GitHub Advanced Security (GHAS) licenses that are required to apply a configuration, or made available by disabling GHAS features on selected repositories. This lets you understand license usage when you roll out GitHub’s code security features in your organization.

Security configurations are now available in public beta on GitHub.com, and will be available in GitHub Enterprise Server 3.14. You can learn more about security configurations or send us your feedback.

See more

Dependabot grouped security updates are now generally available. This feature automatically groups Dependabot pull requests, lets you specify several additional options to fine tune your groupings.

You can enable grouped security updates for Dependabot at the repository or organization-level. To enable this feature, go to your repository or organization settings page, then go to the Code security and analysis tab, and click “Enable” for grouped security updates (this also requires each affected repository to enable Dependency graph, Dependabot alerts, and Dependabot security updates). When you enable this feature, Dependabot will collect all available security updates in a repository and attempt to open one pull request with all of them, per ecosystem, across directories.

If you would like more granular control over Dependabot’s grouping, you can also configure the dependabot.yml file in a repository to group by any of the following:

  • Package name
  • Dependency type (production vs development)
  • Semver update level (patch, minor, major)

For additional information, check out the Dependabot configuration file documentation.

For GitHub Enterprise Server users, grouped security updates will be available in Version 3.14.

See more

Today, we’re releasing a host of new insights to the security overview dashboard, as well as an enhanced secret scanning metrics page.

New dashboard insights

overview dashboard with third-party tools, the trend indicator for age of alerts, and reopened alerts tile highlighted

  • Third-party alerts integration: Beyond GitHub’s own CodeQL, secret scanning, and Dependabot security tools, you can now view alert metrics for third-party tools directly on the overview dashboard. Use tool:[third-party-tool name] to view metrics for a specific third-party security tool, or tool:third-party to view metrics for all third-party security alerts.
  • Reopened alerts tracking: Uncover recurring vulnerabilities with the new reopened alerts metric tile, which identifies vulnerabilities that have resurfaced after being previously resolved. This data point helps assess the long-term effectiveness of your remediation efforts.
  • Trend indicators: Review changes over time with trend indicators for key metrics like age of alerts, mean time to remediate, net resolve rate, and total alert count. These indicators offer a clear view of performance shifts and trends between a given date range and that same range reflected backward in time.
  • Advisories tab: Stay informed with the new advisories table, which details the top 10 alert advisories affecting your organization, including the advisories’ CVE IDs, ecosystems, open alert counts, and severities.

Secret scanning metrics page enhancements

secret scanning metrics page with filter bar highlighted

You can now refine your insights with filters for dates, repository custom properties, teams, and more on the secret scanning metrics page. These new filters empower you to pinpoint specific repositories and view changes over time, enabling a more targeted analysis. Additionally, if you are an organization member, you can now view metrics for the repositories you have access to.

These features are now available as a public beta on GitHub Enterprise Cloud and will be available in GitHub Enterprise Server 3.13.

Learn more about security overview and send us your feedback

See more

Starting today, you can take advantage of the new “age” grouping for the alert trends graph and explore enhanced filter options on the security overview dashboard, aimed at improving your analytical process and security management.

alert trends grouped by age

Explore the dynamics of your security alerts with the new alert age grouping on the alert trends graph. This new functionality offers a refined view into the lifecycle of your security alerts, enabling you to better evaluate the timeliness and effectiveness of your response strategies.

New filter options

repository custom property filter on the security overview page

Leverage enhanced filters to fine-tune your security insights on the overview dashboard:
* Custom repository property filters: With repository custom properties, you can now tag your repositories with descriptive metadata, aiding in efficient organization and analysis across security overview.
* Severity filters: Severity-based filters allow you to concentrate on the vulnerabilities that matter most, streamlining the process of security risk assessment and prioritization.
* Improved date picker controls: Navigate through time with ease using the new date picker options, allowing for quick selection of rolling periods like “Last 14 days,” “Last 30 days,” or “Last 90 days.” Bookmark your preferred time window to keep your analysis current with each visit.

You can access these new functionalities in security overview by navigating to the “Security” tab at the organization level.

These features are now available as a public beta on GitHub Enterprise Cloud and will be available in GitHub Enterprise Server 3.13.

Learn more about security overview and send us your feedback

See more

Dependabot will now fail gracefully with informative error messages when an unsupported NuGet project type is encountered. If you were using an unsupported project type previously, Dependabot might have failed silently without producing updates. Dependabot is able to process updates to NuGet project files in the .csproj, .vbproj, and .fsproj formats.

See more

You can now monitor enablement trends for all security products within your GitHub organization. This functionality is designed to give you a detailed overview of how your organization is implementing security product coverage.

new tool adoption report

Explore enablement trends for historical insights into the activation status of GitHub security features:
* Dependabot alerts
* Dependabot security updates
* Code scanning
* Secret scanning alerts
* Secret scanning push protection

Historical data is available from January 1, 2024, with the exception of Dependabot security updates data, which is available from January 17, 2024.

To access the enablement trends page, visit security overview at the organization level. You can find security overview by clicking on the “Security” tab.

This feature is now available as a public beta on GitHub Enterprise Cloud and will be available in GitHub Enterprise Server 3.13.

Learn more about security overview and join the discussion within the GitHub Community

See more

Previously, if you specified your private registry configuration in the dependabot.yml file and also had a configuration block for that ecosystem using the target-branch key, Dependabot security updates wouldn’t utilize the private registry information as expected. Starting today, Dependabot now uses private registry configurations specified in the dependabot.yml file as expected, even if there is a configuration with target-branch. This ensures that security updates are applied correctly, regardless of your repository’s configuration settings. Note that security updates still does not support target-branch configuration.

Learn more about configuring private registries for Dependabot in the Dependabot documentation.

See more

Previously, if Dependabot encountered 30 consecutive failures, it would stop running scheduled jobs until manual intervention via updating the dependency graph or manifest file. Dependabot will now pause scheduled jobs after 15 failures. This will give an earlier indication of potential issues while still ensuring that critical security updates will continue to be applied without interruption.

Read more in the Dependabot Docs. 

See more

Dependabot security updates help you keep your dependencies secure by opening pull requests when a Dependabot alert is raised. With today’s release, you can now use flexible grouping options in dependabot.yml to control how Dependabot structures its security pull requests to make them more mergeable for you based on your context. Whether you’d like to simply update as many dependencies at once as possible (patterns: '*') or minimize the risk of breaking changes (dependency-type: development or update-types: "patch"), there are grouping options for you.

By specifying applies-to: security-updates in your group rule configuration, you can specify how you would like Dependabot to group your security updates. If you would like Dependabot to group together all possible updates for an ecosystem, you can instead use the UI located in your repository settings to do so. To learn more about this, check out our documentation here.

The available grouping options are:

  • patterns, which will match based on package names
  • dependency-type, which will group based on development or production dependencies, for ecosystems where this is supported, and
  • update-types, which will group based on SemVer level update

Learn more about grouping configuration options here.

See more

If you use private hosted pub repositories or registries to manage your Dart dependencies, Dependabot can now automatically update those dependencies. By adding the details of the private repository or registry to dependabot.yml, Dependabot will be able to access and update these dependencies.

See more

If you’re using starter workflows to prepare the build and release steps for your Java projects that use Gradle, these projects will now have more comprehensive dependency graph information in GitHub. The Gradle starter workflows have been updated to automatically submit transitive dependencies to GitHub, improving the quality of dependency graph data and Dependabot updates for these apps.

Learn more about the action these starter workflows use by checking out the Build with Gradle action on the GitHub Marketplace. Thank you Gradle for making these updates!

Join the discussion within GitHub Community.

See more

If you use devcontainer.json files to define your development containers, you will now be able to use Dependabot version updates to keep your Features up-to-date. Once configured in dependabot.yml, Dependabot will open pull requests on a specified schedule to update the listed Features to latest. This ensures Features are pinned to the latest major version in the associated devcontainer.json file. If a dev container has a lockfile, that file will also be updated. Dependabot security updates for dev containers are not supported at this time.

See more

Reduce pull request noise and fix multiple security alerts at once with Dependabot grouped security updates.

Starting today, you can enable grouped security updates for Dependabot at the repository or organization-level. When you click “Enable” for this feature, Dependabot will collect all available security updates in a repository and attempt to open one pull request with all of them, per ecosystem, across directories. There is no further configuration available at this time.

Known limitations

  • Dependabot will NOT group across ecosystem (e.g. it will not group pip updates and npm updates together)
  • Dependabot WILL group across directories (e.g. if you have multiple package.json’s in different directories in the same repository)
  • If you have version updates enabled as well, Dependabot will NOT group security updates with version updates
  • If you use grouping for version updates, your groups configuration in dependabot.yml will NOT apply to security updates

To enable this feature, go to your repository or organization settings page, then go to the Code security and analysis tab, and click "Enable" for grouped security updates (this also requires each affected repository to enable Dependency graph, Dependabot alerts, and Dependabot security updates). When you enable this feature, Dependabot will immediately attempt to create grouped security pull requests for any available security updates in your repository.

We'd love to hear your feedback as you try this feature! Join the discussion within GitHub Community.

See more

We have partnered with our sister team at Microsoft to bring some improvements to the NuGet ecosystem for Dependabot updates:

  • Updater logic re-written in C#, making it easier for users of NuGet to contribute to dependabot-core
  • Improvement in detection of where package dependencies are declared in .NET projects
  • Improved support for implicit dependencies
  • Improved support for peer dependencies

Learn more about Dependabot.

See more

Auto-triage rules are a powerful tool to help you reduce false positives and alert fatigue substantially, while better managing your alerts at scale. We've heard your feedback, which is helping us improve throughout this beta period.

Starting today, you can now create Dependabot auto-triage rules using CVE IDs or GHSA IDs to target subsets of alerts.

How do I learn more?

How do I provide feedback?

Let us know what you think by providing feedback — we’re listening!

See more

We're simplifying how Dependabot operates! Previously, if Dependabot encountered errors in its last run, it would automatically re-run the job when there were changes in the package manifest (like adding or changing dependencies). This often led to Dependabot running more than needed and creating unscheduled pull requests. To streamline the process and stick to the schedules you set, this automated re-run feature is being deprecated.

Dependabot will still run jobs according to your schedule, and you'll have the option to manually trigger jobs whenever necessary.

See more

Auto-triage rules are a powerful tool to help you reduce alert and pull request fatigue substantially, while better managing your alerts at scale.

What's changing?

Starting today, you can define your own rules to control and enforce Dependabot behaviors across organizations and individual repositories.

  • You can now define which alerts receive pull requests to resolve them, rather than targeting all alerts.
  • You can enable and enforce those Dependabot security update rules across organizations, in addition to individual repositories.
  • You can enable, disable, or enforce how GitHub default rulesets are applied across your organization.
  • You can also now enable and enforce custom auto-dismiss (alert ignore and snooze) rules across organizations.

Dependabot auto-triage rules list

Auto-triage rules are defined by alert targeting criteria, the behaviors you'd like Dependabot to automatically perform for these alerts, as well as how you want the rule to be enabled or enforced across your organization.

Alerts can be targeted based on metadata related to the advisory, dependency, and how it's used. For this public beta, currently supported attributes at the organization level are: severity, scope, package-name, cwe, and ecosystem. At the repository level, you can also target specific manifest files.

Create a stacked Dependabot auto-triage ruleset

For any existing or future alerts that match a custom rule, Dependabot will perform the selected behavior accordingly. You can proactively filter out false positives, snooze alerts until patch release, choose which alerts open Dependabot security updates, and – as rules apply to both future and current alerts – manage existing alerts in bulk.

This feature is free for open source (all public repositories) and available for use in private repositories through GitHub Advanced Security.

Frequently asked questions

Why is GitHub making this change?

At GitHub, we’ve been thinking deeply about how to responsibly address long-running issues around alert fatigue and false positives. Rather than over-indexing on one criterion like reachability or dependency scope, we believe that a responsibly-designed solution should be able to detect and reason on a rich set of complex, contextual alert metadata.

That’s why, moving forward, we’re releasing a series of ships powered by a flexible and powerful alert rules engine. Our first ship – Dependabot presets – leveraged our rules engine with GitHub-curated vulnerability patterns and has helped millions of repositories filter out false positive alerts. Today’s ship exposes our rules engine at the organization and repository levels, so you can create and enforce custom rules, too.

How do I create a rule?

From your organization or repository settings page, admins and security managers can navigate to Code security and analysis settings. Under Dependabot, select Dependabot rules to add or modify your own custom rules or modify GitHub presets.

How do I enforce rules for my organization?

Enforce a Dependabot auto-triage rule

At the organization level, rules can be set with the following states.

State Description
Enabled This rule will be enabled across all eligible repositories in your organization. It will be on by default (new repositories are included). Any individual repository can choose to disable the rule.
Enforced This rule will be enabled across all eligible repositories in your organization. It will be on by default (new repositories are included). Individual repositories cannot override this setting.
Disabled This rule will be disabled and hidden across your organization.

At the repository level, rules can be set to enabled or disabled if they're not enforced.

Which criteria are supported?

Rules can be created across the following attributes:

Attribute Description
severity Alert severity, based on CVSS base score, across the following values: low, medium, high, and critical.
scope Scope of the dependency: development (devDependency) or runtime (production).
package-name Packages, listed by package name.
cwe CWEs, listed by CWE ID.
ecosystem Ecosystems, listed by ecosystem name.
manifest Manifest files, listed by manifest path.

Note: manifest is only available at the repository level.

Target alerts based on attributes

How do I control how Dependabot automatically generates pull requests for alerts?

You can use the alert criteria (above) to indicate which alerts Dependabot will attempt to open pull requests to resolve. To use auto-triage rules with Dependabot updates, you must disable Dependabot's option to always open pull requests to resolve all open alerts from the repository Code security and analysis settings.

How do I control how Dependabot automatically closes or reopens alerts?

Similar to Dependabot pull request rules, you can control how Dependabot filters out false postives (with dismiss indefinitely) or snoozes alerts (with dismiss until patch).

How many custom rules can I create?

At the time of public beta, you can create 20 rules per organization and 10 rules for each repository. Want more? Let us know!

How will this activity be reported?

Auto-dismissal activity is shown in webhooks, REST, GraphQL, and the audit log for Dependabot alerts. Alerts are dismissed without a notification or new pull request and appear as a special timeline event. As these alerts are closed, you’ll still be able to review any auto-dismissed alerts with the resolution:auto-dismissed filter.

Who can create and modify rules?

Auto-triage rules are free for open source repositories. Anyone who can enable Dependabot alerts for a public repository will be able to create custom rules for it. Customers of GitHub Advanced Security can create and manage custom rules across private repositories and at the organization level.

How do I reopen an automatically dismissed alert?

Like any manually dismissed alert, you can reopen an auto-dismissed alert from the alert list view or details page. This specific alert won’t be auto-dismissed again (by any other auto-dismiss rule).

What happens if alert metadata changes or advisory information is withdrawn?

Dependabot recognizes and immediately responds to any changes to metadata which void auto-dismissal logic. For example, if you change the dependency scope and the alert no longer meets the criteria to be auto-dismissed, the alert will automatically reopen.

How do I learn more?

How do I provide feedback?

Let us know what you think by providing feedback — we’re listening!

See more