It means your pull request changes dependencies in a way the check is set to reject, usually because an added or updated package has a known vulnerability. Open the dependency review, find the flagged package, then change the version or pick another package. Do not bypass the check without the owner's approval.
What dependency review shows
GitHub describes dependency review as a way to catch insecure dependencies before you introduce them, with information on license, dependents and age. For pull requests that change manifests or lock files, the review shows which dependencies were added, removed or updated with release dates, how many projects use them, and vulnerability data. It includes changes to indirect dependencies in lock files and tells you whether added or updated dependencies contain known vulnerabilities.
The dependency review action is the piece that reports differences in the context of GitHub Actions and can add enforcement to a workflow. That is the usual source of a red check on a pull request.
Availability depends on the repository: the docs list public repositories, and organization-owned repositories with GitHub Code Security enabled.
Read the failure in order
- Open the check details and the dependency review for the changed manifest or lockfile.
- Find the flagged package, its version and the reason, such as a vulnerability or a rule your team set.
- Decide whether you added it directly or it came as a transitive change from a version bump.
- Check whether a patched version exists.
Choosing a fix
| Cause | Typical fix |
|---|---|
| You added a vulnerable version | Pick the patched version |
| A bump pulled in a vulnerable transitive package | Update the parent or pin the transitive version |
| No patched version exists | Choose another package or ask the owner for a time-boxed exception |
| Policy rule you did not know about | Read your team's policy, then ask |
The GitHub docs make a point worth repeating: if you only meant to update one dependency but the new version also updates its own dependencies, your pull request may have more changes than you expected. The dependency review is how you see that.
Habits that help
- Keep pull requests that change dependencies small and separate from feature work.
- Write one line in the description for each new package: why it is needed.
- Treat the check as a conversation starter, not a hurdle.
See our walkthrough on enabling dependency review on pull requests and the dependency graph explainer.
Where Safeguard fits
Safeguard can do the inventory and watching for you. Its SBOM and dependency scanning lists what a repository actually pulls in, reachability analysis helps separate reachable findings from noise, and policies can gate a pull request. You can try a free scan on a repository to see the output.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what a gate reports on a pull request and what it blocks.
Quick check
Can I just re-run the check until it passes?
No. A re-run does not change the diff. Fix the flagged package or get an agreed exception.
Why did the check fail on a package I did not add?
A version bump can change indirect dependencies. Look at the lockfile section of the review.
Sources
Last reviewed: 19 October 2026.
