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

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

You can now now see the list of recent jobs that Dependabot has run to check for updates and create or rebase pull requests directly from the repository-level dependency graph section of the insights tab. This list will show whether a job was successful, any error messages, and provide links to both the full logs for the job and any pull request affected by the job. This will give you more visibility into the Dependabot process and help you debug.

Screenshot of a list of details about recent Dependabot jobs for a repository

Learn more about troubleshooting Dependabot issues

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.

Starting today, you can now create your own custom rules to control how Dependabot auto-dismisses and reopens alerts – so you can focus on the alerts that matter, without worrying about the alerts that don’t.

What’s changing?

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, and – as rules apply to both future and current alerts – manage existing alerts in bulk.

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 an underlying, all-new, flexible and powerful alert rules engine. Our first ship – Dependabot presets – leveraged our rules engine with GitHub-curated vulnerability patterns. Today’s ship exposes our rules engine so you can create your own rules, too.

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.

What behaviors are supported?

Create or edit a custom rule

Today’s ship covers support for auto-dismissing alerts indefinitely as well as snoozing alerts until patch. Auto-dismissing ensures all activity is easily visible and can be caught by existing reporting systems and workflows, while also ensuring that alerts can be reintroduced if metadata across the alert changes.

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.

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

Dependabot version updates help you keep your dependencies up-to-date by opening pull requests when dependencies can be upgraded. With today's release, you can now use flexible grouping options in dependabot.yml to take control of how Dependabot structures its 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.

Until today, Dependabot would always open individual pull requests for every dependency update in accordance with your configuration in dependabot.yml. Not only can this result in a large number of Dependabot pull requests, but there are some dependencies which must be updated in tandem with each other or the update will fail. In these cases, the individual Dependabot pull requests would always fail until you manually intervened to do the update.

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

At this time, grouping is not available for security updates or Dependabot alerts.

Learn more about grouping configuration options here

See more

Dependabot can now open pull requests to resolve alerts for your Gradle dependencies! If you have used the dependency submission API to upload your Gradle dependencies to the dependency graph and are receiving Dependabot alerts for those dependencies, Dependabot will now try to open a pull request to resolve them automatically if you have security updates enabled for your repository.

See more

If you are using Dependabot grouped version updates (currently in public beta), you can now group your pull requests by semantic version update level. This addition is designed to help reduce the risk of introducing a breaking change through an update.
To use this new functionality, add a new update-types key in your group rule, as shown below:

groups:
  angular:
    patterns:
    - "@angular*"
    update-types:
    - "minor"
    - "patch"

The update-types key accepts values "major," "minor," and "patch," following the SemVer structure of major.minor.patch.

This new key works alongside existing grouping parameters such as patterns, dependency-type, and exclude-patterns, allowing you to fine-tune the grouped pull requests that Dependabot creates for you!

Learn more about configuring grouped Dependabot version updates

See more

As of August 17, 2023, Dependabot updates no longer support Python 3.6 or 3.7, which have reached their end-of-life. If your code uses these versions, Dependabot will no longer be able to open pull requests in your repository and will log errors. Update to at least Python 3.8 to ensure your code is secure and Dependabot can still run.

This change impacts Dependabot pull requests only – you will continue to receive Dependabot alerts for dependencies with known vulnerabilities. To resolve the alert, you can upgrade the affected package yourself manually.

View the official release cycle for Python for more information on supported versions.

Learn more about supported package managers for Dependabot

See more

If you are using the Dependabot grouped version updates feature (currently in public beta), you can now tell Dependabot to ignore updates in the group (similar to how you can do it for Dependabot's individual updates). While closing a grouped pull request will still not create ignore conditions, you can use Dependabot comment commands to tell Dependabot to ignore certain updates in the group – either a specific minor update, a specific major update, or all updates for one dependency.

On a grouped pull request, you can now also tell Dependabot to stop ignoring certain updates that you have already ignored. By commenting @dependabot unignore, you can specify either to stop ignoring a specific range of updates, all updates for a specific dependency, or all updates for every dependency in the group. Dependabot will now also list in the pull request body all the ignore conditions it used to build the pull request. Alternatively, you can comment @dependabot show <dependency-name> ignore conditions and Dependabot will list the ignore conditions for that dependency.

For more information on Dependabot ignore conditions and chat commands, please see the documentation.

See more

If you are using the Dependabot grouped version updates feature (currently in public beta), you can now group your pull requests by dependency type in ecosystems that support this. Instead of listing all the dependencies by name or pattern for your groups, you can now also use the dependency-type key (set to either "production" or "development") to create groups based on dependency type. Then, on your version updates schedule, Dependabot will try to open one pull request to update all available dependencies of that type.

For more information on how to use this feature, check out our documentation on configuring groups for Dependabot pull requests.

See more

As of August 17, 2023, Dependabot will no longer support Python 3.6 or 3.7, which have reached their end-of-life. If your code uses these versions, Dependabot will no longer be able to open pull requests in your repository and will log errors. Update to at least Python 3.8 to ensure your code is secure and Dependabot can still run.

View the official release cycle for Python for more information on supported versions.

See more

pnpm is now fully supported by dependency graph, Dependabot alerts, and Dependabot security updates! If you manage your Node.js dependencies with the pnpm package manager, you can now receive and fix alerts about security vulnerabilities in those dependencies. To use this, enable Dependabot Security Updates from the repository settings page on the code security and analysis tab.

To read more about how to use Dependabot and dependency graph, you can read our documentation here

See more

Dependabot can now open pull requests to update your Swift dependencies. In June, support for Swift advisories in the Advisory Database and Dependabot alerts was released. Dependabot will now be able to open pull requests to fix related alerts, and you will also be able to configure scheduled updates for your dependencies via dependabot.yml.

For more information on how to configure Dependabot updates, please view our documentation here: https://docs.github.com/en/code-security/dependabot

See more