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

Dependabot alerts now show all affected files if your repository code is calling known vulnerable functions from the dependency’s vulnerability. Previously, we only highlighted one of these matches on an alert’s detail page, but now users can view all affected files.

This feature supports our public beta of exposure detection for Python alerts. After beta testing with Python we will add support for other ecosystems. Keep an eye on the public roadmap for more information.

For more information, see our product documentation.

See more

Dependabot will now update @types dependencies alongside their corresponding packages in TypeScript projects.

Before this change, users would see separate pull requests for a package and its corresponding @types package. This could lead to packages and type definitions getting out of sync with one another, and require manual intervention. For example, if a project had dependencies on both jquery and @types/jquery, and a vulnerability triggered Dependabot to update jquery from 3.4.1 to 3.5.0, the package @types/jquery would remain at its original 3.4.x version.

Now, Dependabot can help TypeScript users keep their dependencies and @types packages up-to-date and in sync. When triggered to create an update, Dependabot will check if that package has a corresponding @types package. If so, Dependabot will update both the package and the corresponding @types package in a single PR. Or, if the @types package is no longer needed, that dependency will be removed instead.

The feature is automatically enabled on repositories containing @types packages in the project's devDependencies as listed in package.json. You can disable this behavior by setting the ignore field in your dependabot.yml file to @types/*. Let us know what you think in this feedback discussion.

See more

Dependabot alerts now show if your repository code is calling known vulnerable functions from the dependency's vulnerability. If your code is calling vulnerable code paths, this information is surfaced via a "vulnerable call" label and code snippet in the Dependabot alerts UI. You can also filter for these alerts with has:vulnerable-calls from the Dependabot alert's search field.

Vulnerable functions are curated as part of GitHub's publishing process for the Advisory Database. New incoming Python advisories will be supported, and we're working on backfilling known vulnerable functions for historical Python advisories. After beta testing with Python we will add support for other ecosystems. Keep an eye on the public roadmap for more information.

This feature is enabled for supported Dependabot alerts on public repositories, as well as on repositories with GitHub Advanced Security enabled.

For more information on what we're shipping, read our post in the GitHub blog.

See more

A new DependabotUpdate GraphQL object connects the relevant repository's Dependabot alert(s) – aka vulnerabilityAlerts – to the Dependabot generated pull request or error.

query($repo_owner:String!, $repo_name:String!) {
  repository(owner: $repo_owner, name: $repo_name) {
    vulnerabilityAlerts(first: 1) {
      nodes {
        dependabotUpdate {
          pullRequest {
            number
            title
          }
        }
      }
    }
  }
}
{
  "data": {
    "repository": {
      "vulnerabilityAlerts": {
        "nodes": [
          {
            "dependabotUpdate": {
              "pullRequest": {
                "number": 4772,
                "title": "build(deps): bump object-path from 0.11.5 to 0.11.8 in /npm_and_yarn/helpers"
              }
            }
          }
        ]
      }
    }
  }
}

In some cases, Dependabot fails to open a pull request. Previously, the error message that Dependabot generated was only visible in the Dependabot Alerts section of the Security tab.

Screenshot of Dependabot Security Tab

Now, if Dependabot runs into an error when trying to open a pull request for a Dependabot alert, you can see the error in the API.

query($repo_owner:String!, $repo_name:String!) {
  repository(owner: $repo_owner, name: $repo_name) {
    vulnerabilityAlerts(first: 1) {
      nodes {
        dependabotUpdate {
          pullRequest {
            number
            title
          }
          error {
            title
            body
            errorType
          }
        }
      }
    }
  }
}
{
  "data": {
    "repository": {
      "vulnerabilityAlerts": {
        "nodes": [
          {
            "dependabotUpdate": {
              "pullRequest": null,
              "error": {
                "title": "Dependabot cannot update braces to a non-vulnerable version",
                "body": "The latest possible version of braces that can be installed is `1.8.5`.\n\nThe earliest fixed version is `2.3.1`.",
                "errorType": "security_update_not_possible"
              }
            }
          }
        ]
      }
    }
  }
}

We want your feedback! Let us know how you are using DependabotUpdate and give us your feedback in this GitHub discussion.

See the full API documentation in our GraphQL docs.

See more

Users of Dependabot version updates can now proactively update their dependencies for Flutter or Dart projects which use the pub package manager.

To test version updates on your own Dart or Flutter repo, add the following configuration file in .github/dependabot.yaml:

version: 2
enable-beta-ecosystems: true
updates:
  - package-ecosystem: "pub"
    directory: "/"
    schedule:
      interval: "weekly"

Note the package-ecosystem: "pub" and enable-beta-ecosystems: true flags.

Limitations

Support for pub is in beta, and thus, we are aware of some limitations. For example, security updates are not supported in this release but will be in the future.

Other known limitations:

  • No support for updating git-dependencies
  • If the version found is ignored (by dependabot config) no update will happen (even if, an earlier version could be used)
  • No support for private package repositories

We want your feedback! Please open or vote on a comment in this discussion. You can get help troubleshooting by opening an issue on dependabot-core.

Special thanks to the Dart team for collaborating with us to make this happen.

See more

This release adds support for viewing fixed alerts to the GraphQL API. This update also adds the ability to access and filter by state, as well as access unique numeric identifier.

The additions include these new fields to a RepositoryVulnerabilityAlert:

  • number
  • fixed_at
  • fix_reason
  • state

And we're adding the ability to filter by state on the vulnerability alert object.

For more information, see Dependabot alerts in the GraphQL API reference.

See more

Today, we’re shipping improvements to Dependabot alerts that help you more easily understand and remediate vulnerabilities from dependencies in your codebase.

Persisted Dependabot alerts

Developers can now view alerts that have been fixed in the Dependabot alerts UI.

Included changes:

  • Starting today, fixed Dependabot alerts will now persist and continue to appear under the “closed” tab in the UI
  • All individual alerts now have unique numeric identifiers.

Ungrouped alerts

Previously, Dependabot alerts displayed multiple security advisories grouped by package. Dependabot alerts will now represent a single advisory, rather than being grouped by package.

Included changes:

  • Alerts are now displayed individually (one per advisory and manifest)
  • Previous alert details pages will redirect to a filtered list view by the package name
  • Alert titles will now be more useful to developers and show information about the advisory, rather than just the package name.

This update will not affect Dependabot alert email digests or notifications, Dependabot pull requests, or the GraphQL API.

Learn more about the improvements we’re making to Dependabot alerts in our latest blog post, or read our documentation.

See more

You can now reference local reusable workflows more easily. With this release, reusable workflows that are in the same repository as the calling repository can be referenced with just the path and filename: {path}/{filename}.

For example:

jobs:
  call-workflow-in-local-repo:
    uses: ./.github/workflows/workflow-2.yml

When referenced this way, the called workflow will be from the same commit as the caller workflow.

For questions, visit the GitHub Actions community

To see what's next for Actions, visit our public roadmap

See more

Starting 12-09-2021, GitHub Actions workflows triggered by Dependabot for the create, deployment, and deployment_status events will always receive a read-only token and no secrets.

Starting 12-09-2021, GitHub Actions workflows triggered by Dependabot for the pull_request_target event on pull requests where the base ref was created by Dependabot will always receive a read-only token and no secrets.

Both changes are designed to prevent potentially malicious code from executing in a privileged workflow.

Learn more about using Actions and Dependabot together

For questions, visit the GitHub Actions community

To see what's next for Actions, visit our public roadmap

See more

GitHub Actions workflows triggered by Dependabot will now be sent the Dependabot secrets.

This change will enable you to pull from private package registries in your CI using the same secrets you have configured for Dependabot to use and will improve how Actions and Dependabot work together.

Learn more about using Actions and Dependabot together

For questions, visit the GitHub Actions community

To see what's next for Actions, visit our public roadmap

See more

In March we made a change in GitHub Actions that forced workflows triggered by Dependabot to run with a read-only token. This change was made to protect your repositories from potentially malicious dependencies in the same way we prevent pull requests from forks from having privileged access to your repository. We received a lot of feedback from you on how this impacted your workflows and while it was great to be in a safe configuration by default, you wanted to have the option to continue working as you had prior to this change.

In April we introduced the permissions key in the Actions workflow config which enables you to control which permissions are given to a particular workflow or job.

Starting October 11, 2021 workflow runs on push and pull_request events triggered by Dependabot will begin to respect the permissions specified in your workflows putting you back in control of how you manage automatic dependency updates. The default token permissions will remain read-only.

In addition to the permissions change we are working to enable workflows triggered by Dependabot to use Dependabot secrets. This change will enable you to use those secrets to pull dependencies from private repositories.

Learn more about the permissions key in Actions workflows

For questions, visit the GitHub Actions community

To see what's next for Actions, visit our public roadmap

See more