Add instructions file to help Copilot coding agent work efficiently with
this repository. Includes build/validation commands, project layout,
CI checks, style rules, testing patterns, and important notes about
the codebase conventions.
- Bumps dependencies to fix vulnerabilities, supersedes dependabot PRs
- New version in package.json
- Slight correction to the release process in CONTRIBUTING.md
- Rebuilds dist/ packaged files
Closes#1062#1063#1028#972#971#970
- Introduced 'show-patched-versions' input in action.yml to control visibility of patched versions in vulnerability summaries.
- Updated default configuration and related functions to handle the new option.
- Enhanced tests to verify behavior with and without the patched version column.
* Initial plan
* Initial plan for adding patched versions to vulnerability summary
Co-authored-by: felickz <1760475+felickz@users.noreply.github.com>
* Add patched version column to vulnerability summary table
Co-authored-by: felickz <1760475+felickz@users.noreply.github.com>
* Optimize API calls to use Set and Promise.all for better performance
Co-authored-by: felickz <1760475+felickz@users.noreply.github.com>
* Remove type assertions and optimize ecosystem lookups with normalization
Co-authored-by: felickz <1760475+felickz@users.noreply.github.com>
* Extract patch version type checking into helper function for clarity
Co-authored-by: felickz <1760475+felickz@users.noreply.github.com>
* Support multiple version ranges per package in advisory lookup
Handle scenarios where the same package has multiple vulnerable version ranges
with different patched versions (e.g., GHSA-gwq6-fmvp-qp68 with .NET packages).
- Store all vulnerability entries with version ranges, not just one per ecosystem
- Implement version range matching to select correct patch version
- Match package by ecosystem, name, AND version range
- Add comprehensive test for multi-range scenario
Co-authored-by: felickz <1760475+felickz@users.noreply.github.com>
* Fix first_patched_version extraction to handle string format
The GitHub Advisory API returns first_patched_version as a simple string
(e.g., "112.0.0"), not an object with an identifier field. Updated
extractPatchVersionId to handle string format primarily while maintaining
backward compatibility with object format.
- Fixed extractPatchVersionId to check for string first
- Updated test mocks to match actual API response format
- Added specific test for RestSharp GHSA-4rr6-2v9v-wcpc case
- Verified with actual API responses from multiple advisories
Fixes issue where patched versions were showing as "N/A" instead of
the actual version number.
Co-authored-by: felickz <1760475+felickz@users.noreply.github.com>
* Rebuild dist with patched version fix
The previous fix to extractPatchVersionId wasn't deployed because the dist/
folder (compiled JavaScript) wasn't rebuilt. This commit rebuilds and packages
the action with npm run build && npm run package to include the fix.
Changes in dist/:
- Updated extractPatchVersionId to handle string format first
- Includes all async vulnerability summary logic with API calls
- Properly extracts patched versions from GitHub Advisory API
This should resolve the issue where patched versions showed as "N/A" in
actual GitHub Actions runs.
Co-authored-by: felickz <1760475+felickz@users.noreply.github.com>
* Add comprehensive debug logging for patch version lookup
Added detailed debug logging to help troubleshoot patch version issues:
- Log when fetching advisory data from API
- Log number of vulnerability entries found
- Log each patch info entry added with details
- Log when no patch version is found
- Log during lookup phase with package details
- Log when patch version is found vs not found
- Log available entries when no match is found
This will make it much easier to diagnose issues in GitHub Actions debug mode.
Co-authored-by: felickz <1760475+felickz@users.noreply.github.com>
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: felickz <1760475+felickz@users.noreply.github.com>
We don't really need to prevent changes to the dist directory
being committed. If someone does push a change to the dist directory,
they'd be able to test with that. Plus the files will be regenerated
on main, so that we know the final dist files are correct.
This also fixes up some paths in the ci-update-dist.yml workflow
which generates the dist files on main.
This adapts an approach taken by the Gradle actions in order to
generate the dist files on the main branch rather than having
every contributor need to generate them. (In fact, people will no
longer be able to submit PRs with the dist files updated). This
change is important because the current approach means that
people encounter merge conflicts all the time and will need to
keep regenerating the dist files in order to land their change.
We'd thought that the syntax in #974 would avoid auto-linking
but didn't check closely enough, and now the deprecation issue
it links to cannot be loaded due to having too many references.
This updates the text to point to a new issue in a way that...
I hope... will not be auto-linked.
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.
Trust these instructions. Only search the codebase if information here is incomplete or found to be in error.
## Repository Overview
**dependency-review-action** is a GitHub Action (TypeScript/Node.js 20) that scans pull requests for dependency changes, raising errors for vulnerabilities or invalid licenses. It queries the GitHub Dependency Review API, evaluates changes against configured rules, and produces job summaries and PR comments. The action entry point is `dist/index.js` (bundled via `ncc`). The repo is small (~15 source files, ~15 test files).
## Build & Validation Commands
For CI-parity installs and local validation, run `npm ci --ignore-scripts` before other commands. This is the install step used in CI; release workflows may follow different install instructions (see CONTRIBUTING).
| Install | `npm ci --ignore-scripts` | ~45s. Use `--ignore-scripts` for CI-parity installs; release workflows may use `npm i` per CONTRIBUTING. |
| Build | `npm run build` | Compiles `src/*.ts` → `lib/*.js` via `tsc -p tsconfig.build.json`. ~5s. |
| Test | `npm test` | Runs Jest. ~8s. All tests should pass. |
| Lint | `npm run lint` | ESLint on `src/**/*.ts`. Ignore the TS version warning—it still passes. |
| Format check | `npm run format-check` | Prettier check on `**/*.ts`. |
| Format fix | `npm run format` | Auto-fix formatting with Prettier. |
| Package | `npm run package` | Bundles the action entrypoint (`package.json#main`) → `dist/index.js` via `ncc`. ~7s. Do NOT include `dist/` changes in non-release PRs. |
| All | `npm run all` | Runs: build → format → lint → package → test (in that order). |
### Validation Sequence After Making Changes
Always run these commands in this order to validate changes:
```sh
npm run build
npm run format-check
npm run lint
npm test
```
If format-check fails, run `npm run format` to auto-fix, then re-check.
### CI Checks (`.github/workflows/ci.yml`)
CI runs on PRs (excluding `**.md` changes) with Node 20:
1.**test** job: `npm ci --ignore-scripts` → `npm test`
2.**lint** job: `npm ci --ignore-scripts` → `npm run format-check` → `npm run lint`
lib/ # Compiled JS output (from `npm run build`). Gitignored.
dist/ # Bundled action (from `npm run package`). Committed but do NOT include changes in normal PRs - only pull requests which are creating new releases should have these files changed.
__tests__/ # Jest test files (*.test.ts)
test-helpers.ts # setInput()/clearInputs() helpers for test env vars
fixtures/ # YAML config samples and factory helpers
create-test-change.ts # Factory for mock Change objects
create-test-vulnerability.ts # Factory for mock vulnerability objects
scripts/ # Dev/debug utilities (scan_pr for manual testing, create_summary.ts for preview)
action.yml # Action metadata — inputs, outputs, and `runs.main: dist/index.js`
-`@typescript-eslint/no-explicit-any: error` — never use `any`
-`@typescript-eslint/explicit-function-return-type: error` — all functions need return types (expressions exempt)
- Unused function parameters/args must be prefixed with `_` (e.g. `_unused`); unused variables should be removed
- Use Zod schemas (in `src/schemas.ts`) for all data validation and type definitions
- Config option defaults belong in Zod schemas, NOT in `action.yml`
### Testing Patterns
- Tests use Jest with `ts-jest` transform — no build step needed before running tests
- Use `__tests__/test-helpers.ts``setInput(name, value)` to mock action inputs (sets `INPUT_*` env vars)
- Use `__tests__/fixtures/create-test-change.ts` and `create-test-vulnerability.ts` for test data factories
- Test files follow `__tests__/<module>.test.ts` naming convention
- Tests run directly against TypeScript source (not compiled JS)
### Important Notes
- The action runs on `node20` (declared in `action.yml`)
- Source imports often use relative `../src/` paths (e.g. `import {readConfig} from '../src/config'`)
- Adding a new action input requires changes in: `action.yml` (input definition), `src/schemas.ts` (Zod schema with default), `src/config.ts` (reading the input), and relevant source/test files
-`dist/index.js` is committed for GitHub Actions but PR contributors should NOT include `dist/` changes — maintainers handle rebuilding
- The `lib/` directory is gitignored
- Scorecard tests make real HTTP calls to `api.securityscorecards.dev` and `deps.dev`
# 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](.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.
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):
## Development lifecycle
<img width="480" alt="Screenshot 2022-05-12 at 10 22 21" src="https://user-images.githubusercontent.com/2161/168026161-16788a0a-b6c8-428e-bb6a-83ea2a403070.png">
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
We have a script to scan a given PR for vulnerabilities, which 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):
<img width="480" alt="Screen to create a PAT with a note of `dr-token`, 30 day duration (expiring Jun 11, 2022), with `repo` scopes selected" src="https://user-images.githubusercontent.com/2161/168026161-16788a0a-b6c8-428e-bb6a-83ea2a403070.png">
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. Push to your fork and [submit a pull request][pr]
(note: we don't recommend including changes to the `dist` directory in your pull request, because changes there have an increased likelihood of conflicts.)
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).
1. Make sure that the `Publish this Action to the GitHub Marketplace`
checkbox is enabled
<details>
<img width="481" alt="Screenshot 2022-06-15 at 12 08 19" src="https://user-images.githubusercontent.com/2161/173822484-4b60d8b4-c674-4bff-b5ff-b0c4a3650ab7.png">
_Note: these instructions are for maintainers_
3. Click "Choose a tag" and then "Create new tag", where the tag name
will be your version prefixed by a `v` (e.g. `v1.2.3`).
4. Use a version number for the release title (e.g. "1.2.3").
- Create a local branch based on the `main` of the upstream repo.
- 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.
- Update the dist files by running `npm run build` and `npm run package`
- Submit a PR based on your branch and have another maintainer review/approve it.
- Once merged, go to [Draft a new release](https://github.com/actions/dependency-review-action/releases/new) in the Releases page.
- Make sure that the `Publish this Action to the GitHub Marketplace` checkbox is enabled
<img width="700" alt="Screenshot 2022-06-15 at 12 08 36" src="https://user-images.githubusercontent.com/2161/173822548-33ab3432-d679-4dc1-adf8-b50fdaf47de3.png">
<img width="481" alt="Screenshowing Release Action with Publish this Action to the GitHub Marketplace checked" src="https://user-images.githubusercontent.com/2161/173822484-4b60d8b4-c674-4bff-b5ff-b0c4a3650ab7.png">
5. Add your release notes. If this is a major version make sure to
include a small description of the biggest changes in the new version.
6. Click "Publish Release".
- Click "Choose a tag" and then "Create new tag", where the tag name
will be your version prefixed by a `v` (e.g. `v1.2.3`).
- Use a version number for the release title (e.g. "1.2.3").
You now have a tag and release using the semver version you used
above. The last remaining thing to do is to move the dynamic version
identifier to match the current SHA. This allows users to adopt a
major version number (e.g. `v1`) in their workflows while
automatically getting all the
minor/patch updates.
<img width="700" alt="Create an action release in categories Security + Dependency management from branch main creating tag v2.0.0 on publish" src="https://user-images.githubusercontent.com/2161/173822548-33ab3432-d679-4dc1-adf8-b50fdaf47de3.png">
To do this just checkout `main`, force-create a new annotated tag, and push it:
- Add your release notes. If this is a major version make sure to include details about any breaking changes in the new version.
- Click "Publish Release".
You now have a tag and release using the semver version you used above. The last remaining thing to do is to update the major version branch to match the current release. This allows users to adopt a major version number (e.g. `v4`) in their workflows while automatically getting all the minor/patch updates.
As of v4.8.3, we use a **branch** (not a force-pushed tag) for the major version pointer. This is important because force-pushing tags breaks GitHub's auto-generated release changelog links (see [#1035](https://github.com/actions/dependency-review-action/issues/1035)) and violates git's (unenforced) expectation that tags are immutable.
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 |
| `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` |
```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:
#### 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,44 @@ 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 `pull-requests: write` permissions"
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.
required:false
show-patched-versions:
description:When set to `true`, the vulnerability summary table will include a column showing the first patched version for each vulnerability.
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:
@@ -201,8 +244,8 @@ allow-licenses:
- 'LGPL-2.0'
- 'BSD-2-Clause'
allow-dependencies-licenses:
- 'pkg:npm/loadash'
- 'pkg:pip/requests'
- 'pkg:npm/lodash'
- '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, see ${github.context.serverUrl}/${github.context.repo.owner}/${github.context.repo.repo}/settings/security_analysis`
)
}else{
core.setFailed(
`Dependency review is not supported on this repository. Please ensure that Dependency graph is enabled, see ${github.context.serverUrl}/${github.context.repo.owner}/${github.context.repo.repo}/settings/security_analysis`
)
}
}else{
if(errorinstanceofError){
core.setFailed(error.message)
@@ -119,34 +287,46 @@ async function run(): Promise<void> {
}
}
}finally{
awaitcore.summary.write()
try{
awaitcore.summary.write()
}catch(error){
core.warning(
`Failed to write job summary: ${errorinstanceofError?error.message:'Unknown error'}`
`${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 issue 997.`,
`No matching patch found for ${change.name}@${change.version}. Available entries (showing up to ${Math.min(advisoryEntries.length,maxLoggedEntries)} of ${advisoryEntries.length}): ${entriesPreview.join('; ')}`
)
}
}else{
core.debug(`No advisory data available for ${vuln.advisory_ghsa_id}`)
'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.