How to fix Dependency review found vulnerabilities with severity high or higher in Git

GitINTERMEDIATEHIGH

The 'Dependency review found vulnerabilities' error occurs when GitHub's dependency-review-action detects security vulnerabilities in new or updated dependencies introduced by a pull request. This CI check blocks merging until the vulnerabilities are resolved or explicitly allowed.

What this error means

This error indicates that GitHub's dependency review action has detected one or more security vulnerabilities in the dependencies being added or updated by your pull request. The check is designed to prevent known vulnerable packages from entering your codebase. The dependency-review-action scans your pull request for dependency changes and cross-references them against the GitHub Advisory Database. When it finds dependencies with known vulnerabilities at or above the configured severity threshold (typically "high" or "critical"), it fails the check and blocks the PR from merging. The error message typically includes: - The vulnerability severity level (low, moderate, high, critical) - The affected package name and version - The GitHub Security Advisory ID (GHSA-xxxx-xxxx-xxxx) - A link to the advisory with details about the vulnerability This is a critical security feature because vulnerable dependencies are one of the most common attack vectors in modern software. The 2024 "State of GitHub Actions Security" report found that 18% of custom GitHub Actions in the marketplace had vulnerable dependencies, highlighting how pervasive this issue is across the ecosystem.

How to fix "Dependency review found vulnerabilities with severity high or higher"

1Review the vulnerability details in the workflow summary

First, examine exactly which vulnerabilities were found and understand their impact:

1. Navigate to the Actions tab in your repository
2. Click on the failed workflow run
3. Expand the dependency-review job
4. Look for the Summary section with the "dependency-review summary"

The output will show something like:

bash

Dependency Review
=================

The following vulnerabilities were found:

[email protected]
  GHSA-35jh-r3h4-6jhm (high) - Prototype Pollution
  GHSA-4xc9-xhrj-v574 (high) - Command Injection

[email protected]
  GHSA-cph5-m8f7-6c5x (critical) - Server-Side Request Forgery

Click on the GHSA links to read the full advisory, which includes:
- Detailed vulnerability description
- Affected version ranges
- Patched versions
- Severity explanation
- Proof of concept (if public)

2Update the vulnerable package to a patched version

The recommended solution is to update the vulnerable dependency to a version that contains the security fix:

For npm/Node.js:

bash

# Check for available updates
npm outdated

# Update specific package to latest
npm install lodash@latest

# Or update to a specific patched version
npm install [email protected]

# Update all packages with security issues
npm audit fix

For yarn:

bash

# Check for vulnerabilities
yarn audit

# Update specific package
yarn upgrade [email protected]

# Interactive upgrade
yarn upgrade-interactive --latest

For pip/Python:

bash

# Update specific package
pip install --upgrade requests==2.31.0

# Update requirements.txt
pip-compile --upgrade-package requests

For Bundler/Ruby:

bash

# Update specific gem
bundle update nokogiri

# Check for updates
bundle outdated

After updating, commit the changes and push to trigger a new check:

bash

git add package.json package-lock.json
git commit -m "fix: update lodash to patch security vulnerability"
git push

3Handle transitive dependency vulnerabilities

If the vulnerability is in a transitive dependency (a dependency of your dependency), you have several options:

Option 1: Use npm overrides (Node.js 16.14+)

Add to your package.json:

json

{
  "overrides": {
    "lodash": "4.17.21"
  }
}

Option 2: Use yarn resolutions

Add to your package.json:

json

{
  "resolutions": {
    "lodash": "4.17.21",
    "**/axios": "1.6.0"
  }
}

Option 3: Update the parent package

Sometimes the parent package has already released a version with updated dependencies:

bash

# Find which packages depend on the vulnerable one
npm ls lodash

# Update the parent package
npm install parent-package@latest

Option 4: Use pip constraints (Python)

Create a constraints.txt file:

bash

requests>=2.31.0
urllib3>=2.0.0

Install with constraints:

bash

pip install -c constraints.txt -r requirements.txt

After making changes, regenerate your lock file:

bash

# npm
rm package-lock.json && npm install

# yarn
rm yarn.lock && yarn install

4Allow specific vulnerabilities if they don't apply to your use case

Some vulnerabilities may not affect your application (e.g., server-side vulnerability in client-only code). You can configure the action to skip specific advisories:

Update your workflow file (.github/workflows/dependency-review.yml):

yaml

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:
          # Allow specific vulnerabilities by GHSA ID
          allow-ghsas: 'GHSA-35jh-r3h4-6jhm, GHSA-4xc9-xhrj-v574'

Or use a configuration file (.github/dependency-review-config.yml):

yaml

# Vulnerabilities that don't apply to our use case
allow-ghsas:
  - 'GHSA-35jh-r3h4-6jhm'  # Only affects server-side rendering
  - 'GHSA-4xc9-xhrj-v574'  # Requires user input we don't accept

Reference it in your workflow:

yaml

- uses: actions/dependency-review-action@v4
  with:
    config-file: './.github/dependency-review-config.yml'

Important: Document why each exemption is acceptable. Create a security decision record explaining the risk assessment.

5Adjust the severity threshold for your risk tolerance

If your project has different security requirements, you can adjust when the check fails:

Fail only on critical vulnerabilities:

yaml

- uses: actions/dependency-review-action@v4
  with:
    fail-on-severity: critical

Available severity levels (from most to least strict):
- low - Fails on any vulnerability (default)
- moderate - Fails on moderate, high, and critical
- high - Fails only on high and critical
- critical - Fails only on critical vulnerabilities

Exclude development dependencies:

If you only care about production dependencies:

yaml

- uses: actions/dependency-review-action@v4
  with:
    fail-on-severity: high
    fail-on-scopes: runtime  # Ignore development dependencies

Warning mode for evaluation:

To see vulnerabilities without blocking PRs:

yaml

- uses: actions/dependency-review-action@v4
  with:
    warn-only: true  # Log vulnerabilities but don't fail

Note: Relaxing severity thresholds increases security risk. Only do this after careful consideration of your threat model.

6Configure license checks along with vulnerability checks

The dependency-review-action can also check for problematic licenses. Configure both together:

yaml

- uses: actions/dependency-review-action@v4
  with:
    fail-on-severity: high
    # Only allow these licenses
    allow-licenses: MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC
    # Or deny specific licenses
    # deny-licenses: GPL-3.0, AGPL-3.0

Note: You cannot use both allow-licenses and deny-licenses simultaneously.

Configuration file approach:

yaml

# .github/dependency-review-config.yml
fail-on-severity: high
vulnerability-check: true
license-check: true

allow-licenses:
  - 'MIT'
  - 'Apache-2.0'
  - 'BSD-2-Clause'
  - 'BSD-3-Clause'
  - 'ISC'
  - '0BSD'

# Packages exempt from license check
allow-dependencies-licenses:
  - pkg:npm/some-special-package

This helps ensure you don't accidentally introduce dependencies with incompatible licenses.

7Add PR comments for better visibility

Enable automatic PR comments so reviewers can see vulnerability summaries directly:

yaml

name: 'Dependency Review'
on: [pull_request]

permissions:
  contents: read
  pull-requests: write  # Required for PR comments

jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/dependency-review-action@v4
        with:
          fail-on-severity: high
          comment-summary-in-pr: always  # 'always', 'on-failure', or 'never'

The comment will include:
- Summary of new dependencies
- List of vulnerabilities found
- Severity levels and GHSA links
- License information

This makes it easier for code reviewers to understand and address dependency issues without checking workflow logs.

8Set up Dependabot to prevent future vulnerabilities

Proactively prevent vulnerable dependencies with automated updates:

Create .github/dependabot.yml:

yaml

version: 2
updates:
  # Enable version updates for npm
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10
    # Group minor and patch updates
    groups:
      production-dependencies:
        dependency-type: "production"
        update-types:
          - "minor"
          - "patch"
      development-dependencies:
        dependency-type: "development"
        update-types:
          - "minor"
          - "patch"
    # Security updates have priority
    commit-message:
      prefix: "deps"
      prefix-development: "deps-dev"

  # Enable for Python
  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"

  # Enable for GitHub Actions
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

Enable Dependabot security updates in repository settings:

1. Go to Settings > Security > Code security and analysis
2. Enable "Dependabot alerts"
3. Enable "Dependabot security updates"

Dependabot will automatically create PRs when security vulnerabilities are discovered in your dependencies, often before they cause CI failures.

Advanced notes

### Understanding the GitHub Advisory Database

The dependency-review-action uses the GitHub Advisory Database (GHAD) as its source of vulnerability information. GHAD aggregates vulnerabilities from:
- National Vulnerability Database (NVD)
- npm Security Advisories
- RubyGems Advisory Database
- Python Packaging Advisory Database
- Go Vulnerability Database
- GitHub's own security research team
- Community-submitted advisories

Vulnerabilities are identified by GHSA (GitHub Security Advisory) IDs and often have corresponding CVE numbers.

### How Severity Levels Are Determined

GitHub uses the Common Vulnerability Scoring System (CVSS) to determine severity:

| Severity | CVSS Score | Description |
|----------|------------|-------------|
| Critical | 9.0 - 10.0 | Immediate exploitation likely |
| High | 7.0 - 8.9 | Significant risk, prioritize fix |
| Moderate | 4.0 - 6.9 | Important but less urgent |
| Low | 0.1 - 3.9 | Minor risk, fix when convenient |

### Handling Vulnerabilities Without Fixes

Sometimes a vulnerability exists but no patched version is available:

1. Check if the maintainer is aware - Look at the GitHub issue tracker
2. Evaluate if the vulnerability affects your usage - Many vulns require specific conditions
3. Consider alternative packages - Switch to a maintained fork or competitor
4. Implement mitigations - Input validation, sandboxing, WAF rules
5. Document the risk - If you must proceed, document the decision and timeline for remediation

### Branch Protection Integration

For maximum security, require the dependency review check to pass before merging:

1. Go to Settings > Branches > Branch protection rules
2. Select your main branch
3. Enable "Require status checks to pass before merging"
4. Search and select "dependency-review"

This prevents bypassing the check via force-push or admin merge.

### Working with Monorepos

For monorepos with multiple package files:

yaml

- uses: actions/dependency-review-action@v4
  with:
    # The action automatically detects manifest files
    # But you can specify a base/head ref for comparison
    base-ref: main
    head-ref: ${{ github.head_ref }}

### Caching and Performance

The dependency-review-action caches vulnerability data to speed up subsequent runs. If you're seeing stale data:

yaml

- uses: actions/dependency-review-action@v4
  with:
    # Force fresh vulnerability data (slower)
    retry-on-snapshot-warnings: true

### Enterprise Considerations

For GitHub Enterprise:
- Ensure network access to api.github.com for advisory data
- Consider mirroring the GitHub Advisory Database internally
- Set organization-wide policies for fail-on-severity thresholds
- Use enterprise configuration files for consistent settings across repos

### Supply Chain Security Best Practices

Beyond dependency review, consider:
- Pin action versions to SHA - Prevent supply chain attacks on your CI
- Use `npm ci` instead of `npm install` - Ensures reproducible builds
- Enable npm provenance - Verify package authenticity
- Review SBOM (Software Bill of Materials) - Know your full dependency tree
- Use private package registries - Control what enters your organization

The 2024 tj-actions/changed-files incident showed that a single compromised GitHub Action can affect thousands of repositories. Defense in depth is essential.

How to fix Dependency review found vulnerabilities with severity high or higher in Git

What this error means

Typical symptoms

Common causes

How to fix "Dependency review found vulnerabilities with severity high or higher"

Advanced notes

Related errors

Official resources & further reading