## TL;DR

Open the check's findings, upgrade the flagged packages past their fixed versions, and push - the check re-runs green. Dependency review only scans what your PR changes, so the fix is scoped to the diff. Tune `fail-on-severity` and `allow-licenses` only as deliberate policy, not to silence the gate.

## The error

```text
Dependency Review
2 vulnerable packages detected - failing the check
```

(The check summary or PR comment lists each package, its severity, and the advisory link.)

## Fix it

1. Read the findings. Open the failed "Dependency Review" check and note each package, its severity, and the fixed version in the advisory.
   Expected: 2 entries, each naming the package and the version that fixes it.
2. Upgrade both packages past the fixed versions in your manifest and push.
   Expected: the check re-runs on the new push and passes.
3. If a package cannot be upgraded yet, verify whether your code actually reaches the vulnerable code path. If it does not, document that analysis.
   Expected: a conscious, written decision rather than a quiet suppression.
4. If the failure mixes in license findings, set `allow-licenses` to your team's approved license list in the action config.
   Expected: only genuine license violations fail; approved licenses pass.
5. Confirm the check is green and the merge block is gone.
   Expected: the "Dependency Review" check passes and the PR becomes mergeable.

## Use this when

- The "Dependency Review" check fails the PR with vulnerable packages
- You need to configure `fail-on-severity` or `allow-licenses`
- A dependency bump introduced a new CVE into the diff

## Not for this skill when

- The failing check is snyk or osv-scanner - different tools, different remediation
- The action errors on YAML config syntax - fix the workflow file
- You only need license scanning - see the license-check skill

## Variant phrasings

- dependency review action vulnerable packages
- dependency-review fail-on-severity
- github dependency review failed PR
- dependency review allow-licenses

## Why it happens

The action diffs your PR's dependency changes against the GitHub Advisory Database. A newly added or bumped dependency with a known CVE fails the gate before it can merge. Because it is a diff scanner, it only ever sees what the PR itself changes.

## Edge cases

- A vulnerable dependency already on main will not fail your PR - the action only flags changes in the diff
- Private registries need the packages visible to the API or the action cannot resolve them
- `fail-on-severity: high` still lets medium and low findings through - set the threshold deliberately for your team's risk appetite
- The action needs the dependency graph enabled on the repo; without it the check errors instead of scanning

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_mMuT8KC84aao4hFDKezS8w