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.
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.
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.
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.
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. |
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.
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.
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.
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).
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.
Let us know what you think by providing feedback — we’re listening!
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 namesdependency-type, which will group based on development or production dependencies, for ecosystems where this is supported, andupdate-types, which will group based on SemVer level updateAt this time, grouping is not available for security updates or Dependabot alerts.
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.
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
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.
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.
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.
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.
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
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
You will now be able to see whether Dependabot security updates are enabled or disabled in the security and analysis block within the repository information you can fetch from the REST API, and enable or disable them via API requests.
For more information, you can check out our repository API documentation.
With GHES 3.9, you and your organization can better manage your Dependabot alerts thanks to more granular enablement controls. You can now enable Dependabot alerts at the repository, organization, and enterprise level, rather than having to enable Dependabot alerts across an entire enterprise at once.
This release also adds support for “automatically enable for new repositories” at the organization and enterprise levels.
Enterprise admins still need to opt in to Dependabot alerts via GitHub Connect, which approves outbound calls for advisories to sync.
Learn more about changes for GHES 3.9 for Dependabot.
Dependabot version updates helps you keep your dependencies up-to-date by opening pull requests when dependencies can be upgraded. With today's release, you can now group version updates by dependency name.
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.
Now, in your dependabot.yml configuration file, you can set custom grouping rules for Dependabot based on pattern matching on package name. Here is an example of how these rules can be set up:
version: 2
updates:
- package-ecosystem: "bundler"
directory: "/"
schedule:
interval: weekly
# New!
groups:
# This is the name of your group, it will be used in PR titles and branch names
dev-dependencies:
# A pattern can be...
patterns:
- "rubocop" # a single dependency name
- "aws*" # or a wildcard string that matches multiple dependencies
# If you'd simply like to group as many dependencies together as possible,
# you can use the wildcard * - but keep in mind this may open a very large PR!
# Additionally, you can specify any dependencies to be excluded from the group
exclude-patterns:
- "aws-sdk"This configuration applies to regularly scheduled Dependabot version updates only. Security updates for Dependabot will continue to open as individual pull requests, even if they match a configured grouping rule.
This feature is in beta, so you may encounter instability and the feature-set is currently limited. You may file any bugs encountered in the dependabot-core repo.
To learn more about grouping rules for Dependabot version updates, please refer to our documentation.
Enterprise users will now notice added functionality where Dependabot security and version updates may be paused for repositories.
If you are an enterprise user that uses Dependabot updates and there has been no activity in a repository, such as merging, closing, or any other interaction, with Dependabot pull requests for a period exceeding 90 days, the updates will be paused. To resume activity, simply merge or close one of Dependabot's pull requests, or modify the Dependabot config file in the repository.
This change will help Dependabot be more focused to the repositories you care about and reduce use of GitHub Actions minutes on inactive Dependabot pull requests.
If you are using security overview with GitHub Advanced Security, you will be able to see which repositories in your organization have been paused from the security coverage view.
You will also be able to see whether Dependabot has been paused for a repository by querying the /repos/{owner}/{repo}/automated-security-fixes REST API endpoint, which will return both the enablement status and paused status of the repository.
This change only applies to repositories where Dependabot pull requests exist but remain untouched. If no Dependabot pull requests have been opened, Dependabot will never become paused.
The following must be true for at least 90 days:
Dependabot will add a notice to the body of all open Dependabot pull requests and add a dependabot-paused label to them. Dependabot will also add a banner notice in the UI of your repository settings page (under “Dependabot”) as well as your Dependabot alerts page (if Dependabot security updates are affected).
This change does not apply to Dependabot alerts or subsequent notifications. So, only repositories that have automated Dependabot version updates or security updates, but haven't interacted with these pull requests for a while, will be affected.
Learn more about this change
Learn more about how to interact with the REST API