Optimize Your CI/CD Pipeline
Get instant insights into your CI/CD performance and costs. Reduce build times by up to 45% and save on infrastructure costs.
name: 'Dependency Review'
on: [pull_request]
permissions:
contents: read
jobs:
dependency-review:
runs-on: ubuntu-latest
steps:
- name: 'Checkout Repository'
uses: actions/checkout@v4
- name: 'Dependency Review'
uses: actions/dependency-review-action@v4
dependency-review-action
A GitHub Action for detecting vulnerable dependencies and invalid licenses in your PRs
Dependency Review action scans pull requests for changes in dependencies and can scan for vulnerabilities with licenses not considered valid. Installation includes standard and GitHub Enterprise Server. After the installation of the Dependency Review action, the text then gives options for configuration. With the Dependency Review action already installed, it will continue assisting our vulnerabilities in dependencies by scanning and ultimately flagging issues automatically in pull requests.
This proactive approach ensures that we address any possible vulnerability and license issues before we merge code. It is here that the Dependency Review action enables us to check all the such problems automatically, thereby furthering our security profile and making sure that licensing is complied with. With enforcement through an automated check, the risks associated with embedding vulnerabilities and unauthorized licenses can be significantly reduced, therefore enforcing a safer and more compliant codebase.
How to install the standard Dependency Review action
- Create a new workflow file in the
.GitHub/workflows
directory:name: 'Dependency Review'
on: [pull_request]
permissions:
contents: read
jobs:
DependencyReview:
runs-on: ubuntu-latest
steps:
- name: Check out repository
uses: actions/checkout@v4
- name: Run dependency review
uses: actions/dependency-review-action@v4
This installs minimally and pulls in the Dependency Review action to run on every pull request to check for any issues related to the introduction of a vulnerability or licensing.
Install the Dependency Review action (GitHub Enterprise Server)
Prerequisites:
- GitHub Advanced Security and GitHub Connect are enabled.
- Installing of the dependency-review-action server.
Add a new YAML workflow file under your .github/workflows
directory:
name: 'Dependency Review'
on: [pull_request]
jobs:
dependency-review:
runs-on: [ self-hosted ]
steps:
- name: Checkout Repository
uses: actions/checkout@v4
- name: Dependency Review
uses: actions/dependency-review-action@v4
- **Make sure to replace the value under
runs-on
with`. Under this configuration, which is with GitHub Enterprise Server—here, the Dependency Review Action will run on self-hosted runners over an internal enterprise environment with some specific security requirements.
How to configure Dependency Review Action
Inline Configuration:
Use the with:
the key to specify settings directly in your workflow file
name: 'Dependency Review'
on: [pull_request]
permissions:
contents: read
jobs:
dependency-review:
runs-on: ubuntu-latest
steps:
- name: 'Checkout Repository'
uses: actions/checkout@v4
- name: Dependency Review
uses: actions/dependency-review-action@v4
with:
fail-on-severity: moderate
deny-licenses: LGPL-2.0, BSD-2-Clause
Inline configuration makes it super fast and easy to tweak the dependency review settings in the workflow file for quick testing and iteration of configuration.
-
External Configuration File:
-
Use
config-file
to reference an external configuration file:name: 'Dependency Review'
on: [pull_request]
permissions:
read
jobs:
dependency-review:
runs-on: ubuntu-latest
steps:
- name: 'Checkout Repository'
uses: actions/checkout@v4
- name: Dependency Review
uses: actions/dependency-review-action@v4
with:
config-file: './.github/dependency-review-config.yml' -
Create the configuration file at the specified path and include your settings:
fail_on_severity: 'critical'
allow_licenses:
- 'GPL-3.0'
- 'BSD-3-Clause'
- 'MIT'
This external configuration file helps to keep your workflow file simple and clean with no back drawls of configuration-based complexity, but the configuration can be written in the background. This is indeed quite helpful for keeping settings consistent across many repositories.