When the dependency review summary exceeds GitHub's size limit (1024k), upload it as an artifact and provide a link in the comment. This ensures users can still access the full review details even when the summary is too large to display directly.
The documentation used to say that you needed to transform keys
in external config files from using `-` to `_`, but in reality
the code transforms `-` to `_` regardless of where they occur.
See 4b4ec08f7bCloses#909
The allow-licenses list is expected (and documented) to be a list of
SPDX license IDs (LicenseRefs are also valid). If someone puts an
expression in the list (e.g. "GPL-3.0-only OR MIT"), it should be
discarded so that the whole list does not become invalid.
Fixes#907
When using the `allow-dependencies-licenses` option, the packages listed
there should be allowed even if they have no license. This wasn't
working because the filtering for allowed dependencies was done
specifically on the list of packages that had licenses, leaving a
separate list (unfiltered) for packages with no licenses. With this
change, we filter out any changes for packages that have been allowed
_before_ we retrieve licenses.
Fixes#889
ClearlyDefined uses the string `OTHER` for the declared license when
a human has reviewed `NOASSERTION` text and found it to be a valid
license, but one without an SPDX identifier. `OTHER`, unlike
`NOASSERTION`, is not valid. With this change, when `OTHER` appears
in a license string, we'll replace it with
`LicenseRef-clearlydefined-OTHER`, which _is_ valid and will allow
the expressions to parse.
There are many packages that are dual-licensed, offering a choice
of licenses (e.g. `MIT OR Apache-2.0`). There are some that include
code from multiple sources and require multiple licenses
(e.g. `MIT AND Apache-2.0`). There are also complex combinations that
can exist for a variety of reasons, such as
`MIT AND (Apache-2.0 OR BSD-3-Clause)`.
The most straightforward approach to handle these is to have an
allow list. As long as the licenses on the allow list can satisfy
the license expression of the package in question, it should pass.
To implement this, I the newest release of spdx-satisfies
which changed the interface to be exactly as described
`satisfies(license, allowList)` (see
https://github.com/jslicense/spdx-satisfies.js/pull/17).
Fixes https://github.com/actions/dependency-review-action/issues/263
This change updates license validation to support full SPDX expressions
(such as 'EPL-1.0 AND LGPL-2.1') in both allow-lists and deny-lists. This
enables the action to correctly validate packages that declare multiple
licenses using SPDX conjunctions like AND/OR, which are common in complex
open-source projects.
Previously, only simple license identifiers were supported, which caused
multi-licensed packages to be improperly flagged as invalid even when
they matched the intent of the allow-list.
The new logic uses `spdx.satisfies()` to evaluate whether a package’s
declared license satisfies any expression in the allow/deny list, and
comprehensive tests have been added to verify behavior for various SPDX
combinations.
This improves compatibility with projects using compound SPDX license
expressions and ensures more accurate license policy enforcement.
A clear and concise description of what the bug is.
**To Reproduce**
Steps to reproduce the behavior:
1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error
**Expected behavior**
A clear and concise description of what you expected to happen.
**Screenshots**
If applicable, add screenshots to help explain your problem.
**Action version**
What version of the action are you using in your workflow?
_Note: if you're not running the [latest release](https://github.com/actions/dependency-review-action/releases/latest) please try that first!_
**Examples**
If possible, please link to a public example of the issue that you're encountering, or a copy of the workflow that you're using to run the action.
If you have encountered a problem with a specific package (e.g. issue with license or attributions data) please share details about the package, as well as a link to the manifest where it's being referenced.
# If you wish to specify custom queries, you can do so here or in a config file.
# By default, queries listed here will override any specified in a config file.
# Prefix the list here with "+" to use these queries and those in the config file.
# For more details on CodeQL's query packs, refer to: https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#using-queries-in-ql-packs
stale-pr-message:"👋 This pull request has been marked as stale because it has been open with no activity for 180 days. You can: comment on the PR or remove the stale label to hold stalebot off for a while, add the `Keep` label to hold stale off permanently, or do nothing. If you do nothing, this pull request will be closed eventually by the stalebot. Please see CONTRIBUTING.md for more policy details."
stale-pr-label:"Stale"
close-pr-message:"👋 This pull request has been closed by stalebot because it has been open with no activity for over 180 days. Please see CONTRIBUTING.md for more policy details."
stale-issue-label:"Stale"
stale-issue-message:"👋 This issue has been marked as stale because it has been open with no activity for 180 days. You can: comment on the issue or remove the stale label to hold stalebot off for a while, add the `Keep` label to hold stale off permanently, or do nothing. If you do nothing, this issue will be closed eventually by the stalebot. Please see CONTRIBUTING.md for more policy details."
close-issue-message:"👋 This issue has been closed by stalebot because it has been open with no activity for over 180 days. Please see CONTRIBUTING.md for more policy details."
exempt-pr-labels:"Keep"# a "Keep" label will keep the PR from being closed as stale
exempt-issue-labels:"Keep"# a "Keep" label will keep the issue from being closed as stale
days-before-pr-stale:180# when the PR is considered stale
days-before-pr-close:15# when the PR is closed by the bot
days-before-issue-stale:180# when the issue is considered stale
days-before-issue-close:15# when the issue is closed by the bot
to the public under the [project's open source license](LICENSE).
Contributions to this project are [released](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license) to the public under the [project's open source license](LICENSE).
Please note that this project is released with a [Contributor Code of
Conduct][code-of-conduct]. By participating in this project you agree
to abide by its terms.
Please note that this project is released with a [Contributor Code of Conduct][code-of-conduct]. By participating in this project you agree to abide by its terms.
### How it works
## Bug reports and other issues
This Action makes an authenticated query to the Dependency Graph Diff
API endpoint (`GET /repos/{owner}/{repo}/dependency-graph/compare/{basehead}`)
to find out the set of added and removed dependencies for each manifest.
If you've encountered a problem, please let us know by [submitting an issue](https://github.com/actions/dependency-review-action/issues/new)!
If you've got an idea for a new feature or a significant change to the code or its dependencies, please submit as [an issue](https://github.com/actions/dependency-review-action/issues/new) so that the community can see it, and we can discuss it there. We may not be able to respond to every single issue, but will make a best effort!
### Running the tests
If you'd like to make a contribution yourself, we ask that before significant effort is put into code changes, that we have agreement that the change aligns with our strategy for the action. Since this is a verified Action owned by GitHub we want to make sure that contributions are high quality, and that they maintain consistency with the rest of the action's behavior.
```
npm run test
```
1. Create an [issue discussing the idea](https://github.com/actions/dependency-review-action/issues/new), so that we can discuss it there.
2. If we agree to incorporate the idea into the action, please write-up a high level summary of the approach that you plan to take so we can review
_Note_: We don't have any useful tests yet, contributions are welcome!
## Stalebot
## Local Development
We have begun using a [Stalebot action](https://github.com/actions/stale) to help keep the Issues and Pull requests backlogs tidy. You can see the configuration [here](.github/workflows/stalebot.yml). If you'd like to keep an issue open after getting a stalebot warning, simply comment on it and it'll reset the clock.
## Development lifecycle
Ready to contribute to `dependency-review-action`? Here is some information to help you get started.
### High level overview of the action
This action makes an authenticated query to the [Dependency Review API](https://docs.github.com/en/rest/dependency-graph/dependency-review) endpoint (`GET /repos/{owner}/{repo}/dependency-graph/compare/{basehead}`) to find out the set of added and removed dependencies for each manifest.
The action then evaluates the differences between the pushes based on the rules defined in the action configuration, and summarizes the differences and any violations of the rules you have defined as a comment in the pull request that triggered it and the action outputs.
### Local Development
Before you begin, you need to have [Node.js](https://nodejs.org/en/) installed, minimum version 20.
#### Bootstrapping the project
0. [Fork][fork] and clone the repository
1. Change to the working directory: `cd dependency-review-action`
2. Install the dependencies: `npm install`
3. Make sure the tests pass on your machine: `npm run test`
#### Manually testing for vulnerabilities
It is recommended to have atleast [Node 18](https://nodejs.org/en/) installed.
We have a script to scan a given PR for vulnerabilities, this will
help you test your local changes. Make sure to [grab a Personal Access Token (PAT)](https://github.com/settings/tokens) before proceeding (you'll need `repo` permissions for private repos):
1. Configure and install the dependencies: `npm install`
2. Make sure the tests pass on your machine: `npm run test`
3. Create a new branch: `git checkout -b my-branch-name`
4. Make your change, add tests, and make sure the tests still pass
5. Make sure to build and package before pushing: `npm run build && npm run package`
6. Push to your fork and [submit a pull request][pr]
7. Pat your self on the back and wait for your pull request to be reviewed and merged.
```
npm run test
```
_Note_: We don't have a very comprehensive test suite, so any contributions to the existing tests are welcome!
### Submitting a pull request
1. Create a new branch: `git checkout -b my-branch-name`
2. Make your change, add tests, and make sure the tests still pass
3. Make sure to build and package before pushing: `npm run build && npm run package`
4. Push to your fork and [submit a pull request][pr]
Here are a few things you can do that will increase the likelihood of your pull request being accepted:
-Write tests.
-Add unit tests for new features.
- Keep your change as focused as possible. If there are multiple changes you would like to make that are not dependent upon each other, consider submitting them as separate pull requests.
- Write a [good commit message](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
- Write a [good commit message](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
- Add examples of the usage to [examples.md](docs/examples.md)
- Link to a sample PR in a custom repository running your version of the Action.
- Please be responsive to any questions and feedback that you get from a maintainer of the repo!
## Cutting a new release
1. Update the version number in [package.json](https://github.com/actions/dependency-review-action/blob/main/package.json).
<details>
_Note: these instructions are for maintainers_
1. Update the version number in [package.json](https://github.com/actions/dependency-review-action/blob/main/package.json) and run `npm i` to update the lockfile.
This 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](https://docs.github.com/en/rest/reference/dependency-graph#dependency-review) that diffs the dependencies between any two revisions on your default branch.
- [Option 1: Using inline configuration](#option-1-using-inline-configuration)
- [Option 2: Using an external configuration file](#option-2-using-an-external-configuration-file)
- [`OTHER` in license strings](#other-in-license-strings)
- [Further information](#further-information)
- [Using dependency review action to block a pull request from being merged](#using-dependency-review-action-to-block-a-pull-request-from-being-merged)
- [Outputs](#outputs)
- [Getting help](#getting-help)
- [Contributing](#contributing)
- [License](#license)
The action is available for all public repositories, as well as private repositories that have GitHub Advanced Security licensed.
## Overview
You can see the results on the job logs:
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](https://docs.github.com/en/rest/dependency-graph/dependency-review?apiVersion=2022-11-28) that diffs the dependencies between any two revisions on your default branch.
- Private repositories with a [GitHub Advanced Security](https://docs.github.com/en/enterprise-cloud@latest/get-started/learning-about-github/about-github-advanced-security) license.
**Please keep in mind that you need a [GitHub Advanced Security](https://docs.github.com/en/enterprise-cloud@latest/get-started/learning-about-github/about-github-advanced-security) license if you're running this action on private repositories.**
You can install the action on any public repository, or any organization-owned private repository, provided the organization has a GitHub Advanced Security license.
1. Add a new YAML workflow to your `.github/workflows` folder:
```yaml
name:'Dependency Review'
on:[pull_request]
```yaml
name: 'Dependency Review'
on: [pull_request]
permissions:
contents:read
permissions:
contents: read
jobs:
dependency-review:
runs-on:ubuntu-latest
steps:
- name:'Checkout Repository'
uses:actions/checkout@v3
- name:'Dependency Review'
uses:actions/dependency-review-action@v3
```
jobs:
dependency-review:
runs-on: ubuntu-latest
steps:
- name: 'Checkout Repository'
uses: actions/checkout@v4
- name: 'Dependency Review'
uses: actions/dependency-review-action@v4
```
### GitHub Enterprise Server
#### Installation (GitHub Enterprise Server)
This action is available in Enterprise Server starting with version 3.6. Make sure
are enabled, and that you have installed the [dependency-review-action](https://github.com/actions/dependency-review-action) on the server.
You can install the action on repositories on GitHub Enterprise Server.
You can use the same workflow as above, replacing the `runs-on` value
with the label of any of your runners (the default label
is `self-hosted`):
1. Ensure [GitHub Advanced Security](https://docs.github.com/en/enterprise-server@latest/admin/code-security/managing-github-advanced-security-for-your-enterprise/enabling-github-advanced-security-for-your-enterprise) and [GitHub Connect](https://docs.github.com/en/enterprise-server@latest/admin/github-actions/managing-access-to-actions-from-githubcom/enabling-automatic-access-to-githubcom-actions-using-github-connect) are enabled for the enterprise.
2. Ensure you have installed the [dependency-review-action](https://github.com/actions/dependency-review-action) on the server.
3. Add a new YAML workflow to your `.github/workflows` folder:
```yaml
# ...
```yaml
name: 'Dependency Review'
on: [pull_request]
jobs:
dependency-review:
runs-on:self-hosted
steps:
- name:'Checkout Repository'
uses:actions/checkout@v3
- name:'Dependency Review'
uses:actions/dependency-review-action@v3
```
permissions:
contents: read
## Configuration options
jobs:
dependency-review:
runs-on: self-hosted
steps:
- name: 'Checkout Repository'
uses: actions/checkout@v4
- name: 'Dependency Review'
uses: actions/dependency-review-action@v4
```
Configure this action by either inlining these options in your workflow file, or by using an external configuration file. All configuration options are optional.
4. In the workflow file, replace the `runs-on` value with the label of any of your runners. (The default value is `self-hosted`.)
| 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. | Any [SPDX-compliant identifier(s)](https://spdx.org/licenses/) | none |
| `deny-licenses`\* | Contains a list of prohibited licenses. The action will fail on pull requests that introduce dependencies with licenses that match the list. | Any [SPDX-compliant identifier(s)](https://spdx.org/licenses/) | none |
| `fail-on-scopes`† | 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. | Any GHSAs from the [GitHub Advisory Database](https://github.com/advisories) | none |
| `license-check` | Enable or disable the license check performed by the action. | `true`, `false` | `true` |
| `vulnerability-check` | Enable or disable the vulnerability check performed by the action. | `true`, `false` | `true` |
| `allow-dependencies-licenses`\* | Contains a list of packages that will be excluded from license checks. | Any package(s) in [purl](https://github.com/package-url/purl-spec) format | none |
| `base-ref`/`head-ref` | 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 permission `pull-requests: write`. | `true`, `false` | `false` |
| `deny-packages` | Any number of packages to block in a PR. | Package(s) in [purl](https://github.com/package-url/purl-spec) format | empty |
| `deny-groups` | Any number of groups (namespaces) to block in a PR. | Namespace(s) in [purl](https://github.com/package-url/purl-spec) format (no package name, no version number) | empty |
## Configuration
\*not supported for use with GitHub Enterprise Server
- [Configuration options](#configuration-options)
- [Configuration methods](#configuration-methods)
†will be supported with GitHub Enterprise Server 3.8
### Configuration options
### Inline Configuration
There are various configuration options you can use to specify settings for the dependency review action.
You can pass options to the Dependency Review GitHub Action using your workflow file.
All configuration options are optional.
#### Example
| 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. | Any [SPDX-compliant identifier(s)](https://spdx.org/licenses/) | none |
| `deny-licenses`\* | ⚠️ This option is deprecated for possible removal in the next major release. See [Deprecate the deny-licenses option #938](https://github.com/actions/dependency-review-action/issues/938) for more information. <br> Contains a list of prohibited licenses. The action will fail on pull requests that introduce dependencies with licenses that match the list. | Any [SPDX-compliant identifier(s)](https://spdx.org/licenses/) | none |
| `fail-on-scopes` | 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. | Any GHSAs from the [GitHub Advisory Database](https://github.com/advisories) | none |
| `license-check` | Enable or disable the license check performed by the action. | `true`, `false` | `true` |
| `vulnerability-check` | Enable or disable the vulnerability check performed by the action. | `true`, `false` | `true` |
| `allow-dependencies-licenses`\* | Contains a list of packages that will be excluded from license checks. | Any package(s) in [purl](https://github.com/package-url/purl-spec) format | none |
| `base-ref`/`head-ref` | 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. | Package(s) in [purl](https://github.com/package-url/purl-spec) format | empty |
| `deny-groups` | Any number of groups (namespaces) to block in a PR. | Namespace(s) in [purl](https://github.com/package-url/purl-spec) 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: warning in the CI. | Any positive integer | 3 |
```yaml
name:'Dependency Review'
on:[pull_request]
permissions:
contents:read
jobs:
dependency-review:
runs-on:ubuntu-latest
steps:
- name:'Checkout Repository'
uses:actions/checkout@v3
- name:Dependency Review
uses:actions/dependency-review-action@v3
with:
fail-on-severity:moderate
> [!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**.
# Use comma-separated names to pass list arguments:
deny-licenses:LGPL-2.0, BSD-2-Clause
```
### Configuration methods
### Configuration File
To specify settings for the dependency review action, you can choose from two options:
You can use an external configuration file to specify the settings for this action. It can be a local file or a file in an external repository. Refer to the following options for the specification.
- [Option 1: Inline the configuration options]() in your workflow file.
- [Option 2: Reference an external configuration file]() in your workflow file.
| `config-file` | 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` <br> **External repo**: `github/octorepo/dependency-review-config.yml@main` |
| `external-repo-token` | 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](https://github.com/settings/tokens). | Any token with `read` permissions to the repository hosting the config file. |
#### Option 1: Using inline configuration
#### Example
You can pass configuration options to the dependency review action using your workflow file.
Start by specifying that you will be using an external configuration file:
1. In the same YAML workflow file you created during installation, use the `with:` key to specify your chosen settings:
And then create the file in the path you just specified. Please note
that the **option names in external files use underscores instead of dashes**:
# Use comma-separated names to pass list arguments:
deny-licenses: LGPL-2.0, BSD-2-Clause
```
```yaml
fail_on_severity:'critical'
allow_licenses:
- 'GPL-3.0'
- 'BSD-3-Clause'
- 'MIT'
```
#### Option 2: Using an external configuration file
For more examples of how to use this action and its configuration options, see the [examples](docs/examples.md) page.
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.
### Considerations
1. In the same YAML workflow file you created during installation, use `config-file` to specify that you are using an external configuration file.
- Checking for licenses is not supported on Enterprise Server as the API does not return license information.
- The action will only accept one of the two `license` parameters; an error will be raised if you provide both.
- We don't have license information for all of your dependents. If we can't detect the license for a dependency **we will inform you, but the action won't fail**.
| `config-file` | 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` <br> **External repo**: `github/octorepo/dependency-review-config.yml@main` |
The Dependency Review GitHub Action check will only block a pull request from being merged if the repository owner has required the check to pass before merging. For more information, see the [documentation on protected branches](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-status-checks-before-merging).
2. 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.
| `external-repo-token` | 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](https://github.com/settings/tokens). | Any token with `read` permissions to the repository hosting the config file. |
3. Create the configuration file in the path you specified for `config-file`.
4. In the configuration file, specify your chosen settings.
```yaml
fail-on-severity: 'critical'
allow-licenses:
- 'GPL-3.0'
- 'BSD-3-Clause'
- 'MIT'
```
#### `OTHER` in license strings
License data comes from [ClearlyDefined](https://clearlydefined.io) and you may sometimes see licenses displayed with the string `OTHER` in them. ClearlyDefined [defines OTHER](https://docs.clearlydefined.io/docs/curation/curation-guidelines) 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](https://spdx.org/licenses/), 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](docs/examples.md) page.
- For general information about dependency review on GitHub, see "[About dependency review](https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/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](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-status-checks-before-merging)" in GitHub Docs documentation.
## Outputs
Dependency review action can create [outputs](https://docs.github.com/en/actions/using-jobs/defining-outputs-for-jobs), 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.
> [!NOTE]
> Action outputs are unicode strings [with a 1MB size limit](https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#outputs-for-docker-container-and-javascript-actions).
>
> 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:
# Avoid using default values for options here since they will
# end up overriding external configurations.
# IMPORTANT
#
# Avoid setting default values for configuration options in
# this file, they will overwrite external configurations.
#
# If you are trying to find out the default value for a config
# option please take a look at the README or src/schemas.ts.
#
# If you are adding an option, make sure the Zod definition
# contains a default value.
name:'Dependency Review'
description:'Prevent the introduction of dependencies with known vulnerabilities'
author:'GitHub'
@@ -30,7 +38,7 @@ inputs:
description:Comma-separated list of forbidden licenses (e.g. "MIT, GPL 3.0, BSD 2 Clause")
required:false
allow-dependencies-licenses:
description:Comma-separated list of dependencies in purl format (e.g. "pkg:npm/express, pkg:pip/pycrypto"). These dependencies will be permitted to use any license, no matter what license policy is enforced otherwise.
description:Comma-separated list of dependencies in purl format (e.g. "pkg:npm/express, pkg:pypi/pycrypto"). These dependencies will be permitted to use any license, no matter what license policy is enforced otherwise.
required:false
allow-ghsas:
description:Comma-separated list of allowed GitHub Advisory IDs (e.g. "GHSA-abcd-1234-5679, GHSA-efgh-1234-5679")
@@ -45,14 +53,41 @@ inputs:
description:A boolean to determine if vulnerability checks should be performed
required:false
comment-summary-in-pr:
description:A boolean to determine if the report should be posted as a comment in the PR itself. Setting this to true requires you to give the workflow the write permissions for pull-requests
description:Determines if the summary is posted as a comment in the PR itself. Setting this to `always` or `on-failure` requires you to give the workflow the write permissions for pull-requests
required:false
deny-packages:
description:A comma-separated list of package URLs to deny (e.g. "pkg:npm/express, pkg:pip/pycrypto")
description:A comma-separated list of package URLs to deny (e.g. "pkg:npm/express, pkg:pypi/pycrypto"). If version specified, only deny matching packages and version; else, deny all regardless of version.
required:false
deny-groups:
description:A comma-separated list of package URLs for group(s)/namespace(s) to deny (e.g. "pkg:npm/express, pkg:pip/pycrypto")
description:A comma-separated list of package URLs for group(s)/namespace(s) to deny (e.g. "pkg:npm/express/, pkg:pypi/pycrypto/"). Please note that the group name must be followed by a `/`.
required:false
retry-on-snapshot-warnings:
description:Whether to retry on snapshot warnings
required:false
retry-on-snapshot-warnings-timeout:
description:Number of seconds to wait before stopping snapshot retries.
required:false
warn-only:
description:When set to `true` this action will always complete with success, overriding the `fail-on-severity` parameter.
required:false
show-openssf-scorecard:
description:Show a summary of the OpenSSF Scorecard scores.
required:false
warn-on-openssf-scorecard-level:
description:Numeric threshold for the OpenSSF Scorecard score. If the score is below this threshold, the action will warn you.
config-file-token:${{ secrets.GITHUB_TOKEN }}# or a personal access token
external-repo-token:${{ secrets.GITHUB_TOKEN }}# or a personal access token
```
## Getting the results of the action in the PR as a comment
@@ -155,13 +155,56 @@ jobs:
runs-on:ubuntu-latest
steps:
- name:'Checkout Repository'
uses:actions/checkout@v3
uses:actions/checkout@v4
- name:'Dependency Review'
uses:actions/dependency-review-action@v3
uses:actions/dependency-review-action@v4
with:
fail-on-severity:critical
deny-licenses:LGPL-2.0, BSD-2-Clause
comment-summary-in-pr:true
comment-summary-in-pr:always
```
## Getting the results of the action in a later step
-`comment-content` contains the output of the results comment for the entire run.
`dependency-changes`, `vulnerable-changes`, `invalid-license-changes` and `denied-changes` are all JSON objects that allow you to access individual sets of changes.
```yaml
name:'Dependency Review'
on:[pull_request]
permissions:
contents:read
pull-requests:write
jobs:
dependency-review:
runs-on:ubuntu-latest
steps:
- name:'Checkout Repository'
uses:actions/checkout@v4
- name:'Dependency Review'
id:review
uses:actions/dependency-review-action@v4
with:
fail-on-severity:critical
deny-licenses:LGPL-2.0, BSD-2-Clause
- name:'Report'
# make sure this step runs even if the previous failed
If we were to use configuration file, the configuration would look like this:
@@ -202,7 +245,7 @@ allow-licenses:
- 'BSD-2-Clause'
allow-dependencies-licenses:
- 'pkg:npm/loadash'
- 'pkg:pip/requests'
- 'pkg:pypi/requests'
```
## Only check for vulnerabilities
@@ -222,21 +265,22 @@ jobs:
runs-on:ubuntu-latest
steps:
- name:'Checkout Repository'
uses:actions/checkout@v3
uses:actions/checkout@v4
- name:'Dependency Review'
uses:actions/dependency-review-action@v3
uses:actions/dependency-review-action@v4
with:
fail-on-severity:critical
comment-summary-in-pr:true
comment-summary-in-pr:always
license-check:false
```
## Exclude dependencies from their name or groups
Using the `deny-packages` option you can exclude dependencies by their PURL. You can add multiple values separated by a commas.
With the `deny-packages` option, you can exclude dependencies based on their PURL (Package URL). If a specific version is provided, the action will deny packages matching that version. When no version is specified, the action treats it as a wildcard, denying all matching packages regardless of version. Multiple values can be added, separated by commas.
Using the `deny-groups` option you can exclude dependencies by their group name/namespace. You can add multiple values separated by a comma.
In this example, we are excluding `pkg:maven/org.apache.logging.log4j:log4j-api` and `pkg:maven/org.apache.logging.log4j/log4j-core` from `maven` and all packages in the group `pkg:maven/com.bazaarvoice.maven`
In this example, we are excluding all versions of `pkg:maven/org.apache.logging.log4j:log4j-api` and only `2.23.0` of log4j-core `pkg:maven/org.apache.logging.log4j/log4j-core@2.23.0` from `maven` and all packages in the group `pkg:maven/com.bazaarvoice.maven/`
`Dependency review is not supported on this repository. Please ensure that Dependency graph is enabled along with GitHub Advanced Security on private repositories, see https://github.com/${github.context.repo.owner}/${github.context.repo.repo}/settings/security_analysis`
`Dependency review is not supported on this repository. Please ensure that Dependency graph is enabled along with GitHub Advanced Security on private repositories, see ${github.context.serverUrl}/${github.context.repo.owner}/${github.context.repo.repo}/settings/security_analysis`
)
}else{
if(errorinstanceofError){
@@ -123,30 +250,36 @@ async function run(): Promise<void> {
`${dependency.change.ecosystem}/${dependency.change.name} has an OpenSSF Scorecard of ${dependency.scorecard?.score}, which is less than this repository's threshold of ${config.warn_on_openssf_scorecard_level}.`,
`${icons.warning} <strong>Deprecation Warning</strong>: The <em>deny-licenses</em> option is deprecated for possible removal in the next major release. For more information, see actions/dependency-review-action/issues/938.`,
'See <a href="https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review#best-practices-for-using-the-dependency-review-api-and-the-dependency-submission-api-together">the documentation</a> for more information and troubleshooting advice.'
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.