The dependency review action scans your pull requests for dependency changes, and will raise an error if any vulnerabilities or invalid licenses are being introduced.
The action is supported by an API endpoint that diffs the dependencies between any two revisions on your default branch.
You can install the action on any public repository, or any organization-owned private repository, provided the organization has a GitHub Advanced Security license.
Note: Dependency Review Action v5.0.0 updates the runtime to node24. This requires a minimum Actions Runner version v2.327.1 to run.
Add a new YAML workflow to your .github/workflows folder:
There are various configuration options you can use to specify settings for the dependency review action.
All configuration options are optional.
Option
Usage
Possible values
Default value
fail-on-severity
Defines the threshold for the level of severity. The action will fail on any pull requests that introduce vulnerabilities of the specified severity level or higher.
low, moderate, high, critical
low
allow-licenses*
Contains a list of allowed licenses. The action will fail on pull requests that introduce dependencies with licenses that do not match the list.
⚠️ This option is deprecated for possible removal in the next major release. See Deprecate the deny-licenses option #938 for more information. Contains a list of prohibited licenses. The action will fail on pull requests that introduce dependencies with licenses that match the list.
Contains a list of strings of the build environments you want to support. The action will fail on pull requests that introduce vulnerabilities in the scopes that match the list.
runtime, development, unknown
runtime
allow-ghsas
Contains a list of GitHub Advisory Database IDs that can be skipped during detection.
Provide custom git references for the git base/head when performing the comparison check. This is only used for event types other than pull_request and pull_request_target.
Any valid git ref(s) in your project
none
comment-summary-in-pr
Enable or disable reporting the review summary as a comment in the pull request. If enabled, you must give the workflow or job the pull-requests: write permission. With each execution, a new comment will overwrite the existing one.
always, on-failure, never
never
deny-packages
Any number of packages to block in a PR. This option will match on the exact version provided. If no version is provided, the option will treat the specified package as a wildcard and deny all versions.
Any number of groups (namespaces) to block in a PR.
Namespace(s) in purl format (no package name, no version number)
empty
retry-on-snapshot-warnings*
Enable or disable retrying the action every 10 seconds while waiting for dependency submission actions to complete.
true, false
false
retry-on-snapshot-warnings-timeout*
Maximum amount of time (in seconds) to retry the action while waiting for dependency submission actions to complete.
Any positive integer
120
warn-only+
When set to true, the action will log all vulnerabilities as warnings regardless of the severity, and the action will complete with a success status. This overrides the fail-on-severity option.
true, false
false
show-openssf-scorecard
When set to true, the action will output information about all the known OpenSSF Scorecard scores for the dependencies changed in this pull request.
true, false
true
warn-on-openssf-scorecard-level
When show-openssf-scorecard-levels is set to true, this option lets you configure the threshold for when a score is considered too low and gets a warning in the CI.
Any positive integer
3
show-patched-versions*
When set to true, the vulnerability summary table will include an additional column showing the first patched version for each vulnerability. This requires additional API calls to fetch advisory data.
true, false
false
[!NOTE]
* Not supported for use with GitHub Enterprise Server. (Checking for licenses is not supported on GitHub Enterprise Server because the API does not return license information.)
+ When warn-only is set to true, all vulnerabilities, independently of the severity, will be reported as warnings and the action will not fail.
The allow-licenses and deny-licenses options are mutually exclusive; an error will be raised if you provide both.
If we can’t detect the license for a dependency we will inform you, but the action won’t fail.
Configuration methods
To specify settings for the dependency review action, you can choose from two options:
A path to a file in the current repository or an external repository. Use this syntax for external files: OWNER/REPOSITORY/FILENAME@BRANCH
Local file: ./.github/dependency-review-config.yml External repo: github/octorepo/dependency-review-config.yml@main
Optionally, if the file resides in a private external repository, and for all GitHub Enterprise Server repositories, use external-repo-token to specify a token for fetching the file.
Specifies a token for fetching the configuration file. It is required if the file resides in a private external repository and for all GitHub Enterprise Server repositories. Create a token in developer settings.
Any token with read permissions to the repository hosting the config file.
Create the configuration file in the path you specified for config-file.
In the configuration file, specify your chosen settings.
License data comes from ClearlyDefined and you may sometimes see licenses displayed with the string OTHER in them. ClearlyDefined defines OTHER as:
This indicates that a human confirmed that there is license information in the file but that the license is not an SPDX-identified license.
OTHER is not a valid SPDX license identifier, so we convert OTHER in a license string into LicenseRef-clearlydefined-OTHER, which is valid in SPDX. If you want to add that to the deny or allow list, be sure to add LicenseRef-clearlydefined-OTHER to this list, because that is what we’ll actually be comparing.
Further information
For more examples of how to use this action and its configuration options, see the examples page.
For general information about dependency review on GitHub, see “About dependency review“ in the GitHub Docs documentation.
Using dependency review action to block a pull request from being merged
You can configure your repository to block a pull request from being merged if the pull request fails the dependency review action check. To do this, the repository owner must configure branch protection settings that require the check to pass before merging. For more information, see “Require status checks before merging“ in GitHub Docs documentation.
Outputs
Dependency review action can create outputs, so that data from its execution can be used by other jobs in a workflow.
comment-content is generated with the same content as would be present in a Dependency Review Action comment.
dependency-changes holds all dependency changes in a JSON format. The following outputs are subsets of dependency-changes filtered based on the configuration:
vulnerable-changes holds information about dependency changes with vulnerable dependencies in a JSON format.
invalid-license-changes holds information about invalid or non-compliant license dependency changes in a JSON format.
denied-changes holds information about denied dependency changes in a JSON format.
If you use these outputs in a run-step, you must store the output data in an environment variable instead of using the output directly. Using an output directly might break shell scripts. For example:
dependency-review-action
OTHERin license stringsOverview
The dependency review action scans your pull requests for dependency changes, and will raise an error if any vulnerabilities or invalid licenses are being introduced. The action is supported by an API endpoint that diffs the dependencies between any two revisions on your default branch.
The action is available for:
Viewing the results
When the action runs, you can see the results on:
The job logs page.
The job summary page.
Go to the Actions tab for the repository and select the relevant workflow run.
Click Summary, then scroll to “dependency-review summary”.
Installation
Installation (standard)
You can install the action on any public repository, or any organization-owned private repository, provided the organization has a GitHub Advanced Security license.
Add a new YAML workflow to your
.github/workflowsfolder:Installation (GitHub Enterprise Server)
You can install the action on repositories on GitHub Enterprise Server.
Ensure GitHub Advanced Security and GitHub Connect are enabled for the enterprise.
Ensure you have installed the dependency-review-action on the server.
Add a new YAML workflow to your
.github/workflowsfolder:In the workflow file, replace the
runs-onvalue with the label of any of your runners. (The default value isself-hosted.)Configuration
Configuration options
There are various configuration options you can use to specify settings for the dependency review action.
All configuration options are optional.
fail-on-severitylow,moderate,high,criticallowallow-licenses*deny-licenses*Contains a list of prohibited licenses. The action will fail on pull requests that introduce dependencies with licenses that match the list.
fail-on-scopesruntime,development,unknownruntimeallow-ghsaslicense-checktrue,falsetruevulnerability-checktrue,falsetrueallow-dependencies-licenses*base-ref/head-refpull_requestandpull_request_target.comment-summary-in-prpull-requests: writepermission. With each execution, a new comment will overwrite the existing one.always,on-failure,neverneverdeny-packagesdeny-groupsretry-on-snapshot-warnings*true,falsefalseretry-on-snapshot-warnings-timeout*warn-only+true, the action will log all vulnerabilities as warnings regardless of the severity, and the action will complete with asuccessstatus. This overrides thefail-on-severityoption.true,falsefalseshow-openssf-scorecardtrue, the action will output information about all the known OpenSSF Scorecard scores for the dependencies changed in this pull request.true,falsetruewarn-on-openssf-scorecard-levelshow-openssf-scorecard-levelsis set totrue, this option lets you configure the threshold for when a score is considered too low and gets ashow-patched-versions*true, the vulnerability summary table will include an additional column showing the first patched version for each vulnerability. This requires additional API calls to fetch advisory data.true,falsefalseConfiguration methods
To specify settings for the dependency review action, you can choose from two options:
Option 1: Using inline configuration
You can pass configuration options to the dependency review action using your workflow file.
In the same YAML workflow file you created during installation, use the
with:key to specify your chosen settings:Option 2: Using an external configuration file
You can use an external configuration file to specify settings for this action. The file can be a local file or a file in an external repository.
In the same YAML workflow file you created during installation, use
config-fileto specify that you are using an external configuration file.config-fileOWNER/REPOSITORY/FILENAME@BRANCH./.github/dependency-review-config.ymlExternal repo:
github/octorepo/dependency-review-config.yml@mainOptionally, if the file resides in a private external repository, and for all GitHub Enterprise Server repositories, use
external-repo-tokento specify a token for fetching the file.external-repo-tokenreadpermissions to the repository hosting the config file.Create the configuration file in the path you specified for
config-file.In the configuration file, specify your chosen settings.
OTHERin license stringsLicense data comes from ClearlyDefined and you may sometimes see licenses displayed with the string
OTHERin them. ClearlyDefined defines OTHER as:OTHERis not a valid SPDX license identifier, so we convertOTHERin a license string intoLicenseRef-clearlydefined-OTHER, which is valid in SPDX. If you want to add that to the deny or allow list, be sure to addLicenseRef-clearlydefined-OTHERto this list, because that is what we’ll actually be comparing.Further information
Using dependency review action to block a pull request from being merged
You can configure your repository to block a pull request from being merged if the pull request fails the dependency review action check. To do this, the repository owner must configure branch protection settings that require the check to pass before merging. For more information, see “Require status checks before merging“ in GitHub Docs documentation.
Outputs
Dependency review action can create outputs, so that data from its execution can be used by other jobs in a workflow.
comment-contentis generated with the same content as would be present in a Dependency Review Action comment.dependency-changesholds all dependency changes in a JSON format. The following outputs are subsets ofdependency-changesfiltered based on the configuration:vulnerable-changesholds information about dependency changes with vulnerable dependencies in a JSON format.invalid-license-changesholds information about invalid or non-compliant license dependency changes in a JSON format.denied-changesholds information about denied dependency changes in a JSON format.Getting help
If you have bug reports, questions or suggestions please create a new issue.
Contributing
We are grateful for any contributions made to this project. Please read CONTRIBUTING.MD to get started.
License
This project is released under the MIT License.