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

Starting today, Dependabot will be able to auto-dismiss npm alerts that have limited impact (e.g. long-running tests) or are unlikely to be exploitable. With this ship, Dependabot will cut false positives and reduce alert fatigue substantially.

On-by-default for public repositories, and opt-in for private repositories, this feature will result in 15% of low impact npm alerts being auto-dismissed moving forward – so you can focus on the alerts that matter, without worrying about the ones that don’t.

What’s changing?

When the feature is enabled, Dependabot will auto-dismiss certain types of vulnerabilities that are found in npm dependencies used in development (npm devDependency alerts with scope:development). This feature will help you proactively filter out false positives on development-scoped (non-production or runtime) alerts without compromising on high risk devDependency alerts.

Dependabot alerts auto-dismissal list view

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. Today’s ship, our first application, leverages GitHub-curated vulnerability patterns to help proactively filter out false positive alerts.

Why auto-dismissal, rather than purely suppressing these alerts?

Auto-dismissing ensures any ignored alerts are 1) able to be reintroduced if alert metadata changes, 2) caught by existing reporting systems and workflows, and 3) extensible as a whole to future rules-based actions, where Dependabot can decision on subsets of alerts and do things like reopen for patch, open a Dependabot pull request, or even auto-merge if very risky.

How does GitHub identify and detect low impact alerts?

Auto-dismissed alerts match GitHub-curated vulnerability patterns. These patterns take into account contextual information about how you’re using the dependency and the level of risk they may pose to your repository. To learn more, see our documentation on covered classes of vulnerabilities.

How will this activity be reported?

Auto-dismissal activity is supported across webhooks, REST, GraphQL, and the audit log for Dependabot alerts. In addition, you can review your closed alert list with the resolution:auto-dismissed filter.

How will this experience look and feel?

Alerts identified as false positives will be automatically dismissed without a notification or new pull request, and appear as 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.

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.

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 can I enable or disable the feature?

This feature is on-by-default for public repositories and opt-in for private repositories. Repository admins can opt in or out from your Dependabot alerts settings in the Code Security page.

Is this feature available for enterprise?

Yes! In addition to all free repositories, this feature will ship immediately to GHEC and to GHES in version 3.10.

What’s next?

Next, we’ll expose our underlying engine – which enables Dependabot to perform actions based on a rich set of contextual alert metadata – so you can write your own custom rules to better manage your alerts, too.

How do I learn more?

How do I provide feedback?

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

See more

When changes in a repository make a Dependabot pull request out-of-date, Dependabot will automatically rebase it so that it is able to be merged without your manual effort. With this release, if a PR has not been merged for 30 days, Dependabot will stop rebasing it and will include a note about this in the PR body. You will still be able to manually rebase and merge the pull request. We've heard your feedback about Dependabot noisiness and are making Dependabot quieter and more focused on repositories you care about. For enterprise customers, this improvement has the added benefit of enhanced efficiency with your self-hosted GitHub Actions runners. For Enterprise Server customers, this update will be available to you in GHES 3.10.

See more

You can now fetch release notes, changelogs and commit history for Docker update pull requests with Dependabot. This will allow you to quickly evaluate the stability risk of the dependency upgrade. To enable support, add the org.opencontainers.image.source label to the Dockerfile with the URL of the source repository. Additionally, the repository should be tagged with the same tags as the published Docker images. This allows Dependabot to understand which repo and commit is associated each version/tag of a Docker image. Here's an example repository demonstrating this setup.

Did you know? Dependabot's internal library for identifying dependency updates is open source. If you notice a Dependabot pull request is missing metadata, you can leverage the transparency of open source to debug the root cause – for example, if the package maintainer needs to fix their metadata annotation.

See more

What’s new?

This feature makes it easier to enable Dependabot alerts and check enablement status across all your repositories at an enterprise level, with updates across both enablement UI and APIs. These updates will ship today for GitHub.com and will ship for GitHub Enterprise Server users in 3.9.

Changes to the REST API

Dependabot alerts have been added to existing endpoints:

‘Code security and analysis’ settings

You can also adjust your enablement settings from your enterprise settings page (under ‘code security and analysis’). Options include enable all, disable all, and enable for new repositories for your enterprise.

Enable Dependabot alerts

Learn more about Dependabot alerts

See more

What's new?

Starting today, anyone with repository write or maintain roles will be able to view and act on Dependabot alerts by default. Previously, only repository admins could view and act on Dependabot alerts. This change will help ensure that alerts are visible to the same developers responsible for fixing them.

How do I opt in?

No action needed–this change will be applied to all existing and new repositories starting today.

What's not changing?

This doesn’t affect custom roles, the Security Manager role, or organization permissions for Dependabot alerts. Only repository admins can enable or disable Dependabot alerts.

What about alert notifications?

This change also will not affect your alert notification or repository watching settings. So, if you aren’t opted in to Dependabot alert notifications based on your user settings, you won’t receive any.

If you are currently receiving notifications on alerts, any new repositories will be included with existing Dependabot alerts notifications.

Learn more about this change here.

See more

Starting today, when linking to a Dependabot alert in an issue and or pull requests, anyone with permissions to view the alert will see a rich Dependabot alert mention, with detailed hovercard and a prettified link with the title of the alert.

Card details include:

  • Alert title, repository, and description
  • Date that the alert was opened
  • Alert severity and status (fixed, dismissed, or open).

Dependabot alerts - prettified links and hovercard example

Learn more about Dependabot alerts

See more

What’s new?

Starting today, Dependabot will pause automated pull request activity if you haven’t merged, closed, or otherwise interacted with Dependabot for over 90 days. To resume activity when you’re ready, simply interact with Dependabot.

This change will help Dependabot be more focused to the repositories you care about.

When will Dependabot become paused?

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:

  • Has not had a Dependabot PR merged
  • Has not had changes made to the Dependabot config file
  • Has not had any @dependabot comment-ops performed
  • Has not had any Dependabot PRs closed by the user
  • Has received at least one Dependabot PR before the 90 day window
  • Has at least one Dependabot PR open at the end of the 90 day window
  • Has had Dependabot enabled for this entire period

How will Dependabot let me know?

Dependabot will add a banner notice to open Dependabot pull requests, the repository settings page (under “Dependabot”) as well as your Dependabot alerts page (if Dependabot security updates are affected).

Who can use this feature?

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.

This change will start to roll out today, expanding through January 2023 to include all repositories owned by individuals and by organizations with free and Team plans.

Later, it will roll out to GitHub Enterprise Cloud and GitHub Enterprise Server customers, where this improvement has the added benefit of enhanced efficiency with your self-hosted GitHub Actions runners.

Learn more about this change.

See more

Dependabot security updates now supports the Pub ecosystem, making it easier for you to fix vulnerable dependencies in your Dart or Flutter apps. With security updates enabled, Dependabot will automatically raise a pull request to update vulnerable Pub dependencies to the latest patched version.

Learn more about Dependabot security updates.

See more

GitHub's audit log allows organization and enterprise admins to quickly review the actions performed by members of their organization or enterprise. For Dependabot alerts, the audit log includes actions such as repository enablement, creation or reintroduction of alerts, dismissal of alerts, and resolving of alerts.

The audit log now supports the following improvements:

  • Dismissal comments, if provided with a Dependabot alert, are now displayed in the audit log
  • The audit log API for Dependabot alerts now supports several new fields: alert_number, ghsa_id, dismiss_reason, and dismiss_comment.
  • Additional minor improvements, including links back to the alert and correct timestamps added to events.

This release is available for organization and enterprise admins (including GHES 3.7 and later).

For more information, view documentation on Dependabot alerts in the GitHub audit log.

See more

Dependabot expands its existing Hex private registry support beyond Hex organizations by adding support for self-hosted Hex repositories. You can configure your self-hosted Hex package repository as a private registry for use with Dependabot version updates. Special thanks to @sorentwo for their contribution to Dependabot!

Learn more about configuring Dependabot version updates and its supported ecosystems and package managers.

See more