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 unlocks transitive dependencies for npm projects

Your GitHub repositories with Dependabot alerts enabled and Dependabot security updates enabled will automatically generate Dependabot pull requests for vulnerable npm transitive dependencies.

Previously, Dependabot couldn't generate a security update for a transitive dependency when its parent dependency required incompatible specific version range. In this locked state, developers had to manually upgrade the parent and transitive dependencies.

Now, Dependabot will be able to create pull requests for npm projects that upgrade both the parent and child dependencies together.

For example, if a vulnerability for the transitive dependency node-forge triggers a Dependabot alert and allows a PR to be created:

2 generated security update white bg

Prior to this change Dependabot would fail to create a Dependabot security update for transitive dependencies 😕. But not anymore! 😁 Now, Dependabot will unlock the node-forge security update by bumping the parent webpack-dev-server version in addition to patching the `node-forge dependency within the same Pull Request!

3 update PR white bg

This change will apply to pull requests generated by Dependabot that update vulnerable npm packages.

See more

Differentiating triggering actor from executing actor

Starting next week, workflow re-runs in GitHub Actions will use the initial run’s actor for privilege evaluation. The actor who triggered the re-run will continue to be displayed in the UI, and can be accessed in a workflow via the triggering_actor field in the github context.

Currently, the privileges (e.g. – secrets, permissions) of a run are derived from the triggering actor. This poses a challenge in situations where the actor triggering a re-run is different than the original executing actor. The upcoming change will differentiate the initial executing actor from the triggering actor, enabling the stable execution of re-runs.

For more details see Re-running workflows and jobs.

For questions, visit the GitHub Actions community.

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

See more

Dependabot alerts are now ranked by most important priority

Dependabot alerts will now be easier to prioritize with a new “Most Important” sort. For the alerts repository list view, by default, alerts will be sorted in a way to help you determine which alerts matter most. You will still be able to access additional sort options, like sort by Newest, CVSS severity, and Manifest path in the UI.

This “Most Important” sort considers CVSS score as the primary factor, along with additional factors across vulnerability impact (potential risk), relevancy, and actionability (how easy the vulnerability is to fix). For example, when supported, this sort calculation takes into consideration whether you’re calling a vulnerable function, as well as dependency scope (e.g. if an alert is a devDependency). This calculation will be improved over time.

This functionality will not affect Dependabot pull requests, the org-level list view of Dependabot alerts, or the GraphQL API.

For more information, see our documentation for Dependabot alerts.

See more

Dependabot alerts paused for malware advisories

On June 15th, we announced GitHub added malware advisories to the GitHub Advisory Database and will send malware alerts through Dependabot. Since shipping this change, we have received feedback that some organizations have been impacted with Dependabot alerts from these malware advisories that may be false positives.

GitHub has conducted a rapid root cause investigation and found that the majority of those alerts in question were for substitution attacks. During these types of incidents, an attacker would publish a package to the public registry with the same name as a dependency users rely on from a third party or private registry, in the hope a malicious version would be consumed. Dependabot doesn’t look at project configuration to determine if the packages are coming from a private registry, so it has been triggering an alert for packages with the same name from the public npm registry. While this does mean that your package was the target of a substitution attack it does not mean that there is an immediate action to be taken on your part as the malware has already been removed from the npm registry.

While we work to determine how to best notify customers of being the target of a substitution attack, we will be pausing all Dependabot notifications on malware advisories. For non-Enterprise-Server users, Malware advisories will still exist in the Advisory Database and send alerts on npm audit. We are not making any changes to existing alerts on github.com at this time.

For GitHub Enterprise Server users, who were the most impacted, no new advisories will come through GitHub Connect. If you are struggling with too many alerts, please reach out to support and we can share a script for you to run that will delete all malware advisories and alerts.

See more

Dependabot alerts: Dependency scope filter via GraphQL API

When using the GraphQL API, you can now filter Dependabot alerts by the scope of the dependency affected. The possible scopes are DEVELOPMENT or RUNTIME.

Dependency scope information is available for alerts opened on or after June 23, 2022, and can also be viewed in the Dependabot alerts UI as of last week.

For more information, see Dependabot alerts in the GraphQL API reference or learn more about Dependabot alerts in our documentation.

See more

Dependabot alerts: Filter alerts by the scope of the dependency (runtime and development)

Today, we're shipping a new filter for the Dependabot alerts list view. In the alerts list view, you can now filter for scope:development or scope:runtime. Alerts for development dependencies also feature a label in the UI.

Dependency scope information will be available for alerts opened on or after June 23, 2022.

Which ecosystems are supported?

The following ecosystems are supported as of June 23, 2022:

Language Ecosystem Dependency Scope
Ruby RubyGems ✅
JavaScript npm ✅
JavaScript Yarn No, defaults to runtime
PHP Composer ✅
Go Go modules No, defaults to runtime
Java Maven ✅ test maps to development, all else default to runtime
Python Poetry ✅
Python pip ✅ for pipfile, for requirements.txt scope is development if the filename contains “test” or “dev”, else it is runtime
.NET NuGet ✅ only for .nuspec when tag != runtime; for all other cases defaults to runtime
Rust Cargo ✅

For more information, learn more about Dependabot alerts in our documentation.

See more

Advisory Database supports malware advisories

GitHub's Advisory Database now supports listing malware advisories. You can see them by searching "type:malware" on https://github.com/advisories.

If you have enabled Dependabot alerts on your repositories, GitHub will send Dependabot alerts for malware automatically. Note that Dependabot does not send update pull requests for malware as the only resolution is to delete the package and find an alternative.

See more

Enable Dependabot version updates from the repository settings page

Dependabot version updates help you keep your dependencies up-to-date by opening pull requests automatically when new versions are available.

With this release, you can now more easily enable and configure Dependabot version updates from your repository’s settings page. Within the "Dependabot" section of the "Code security and analysis" tab, you can choose to enable Dependabot version updates, which will prompt you to create a dependabot.yml config file. If a dependabot.yml file exists, you can access that from the repository settings page.

Note: you still need to configure Dependabot version updates with a dependabot.yml file to enable it.

For more information, learn more about Dependabot version updates and how to configure a dependabot.yml file.

See more

Dependabot alerts show all affected files for vulnerable function calls (Python Beta)

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 keeps `@types` dependencies in sync with updated packages

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 show vulnerable function calls (Python Beta)

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
View more changes