A dependency review check should block pull requests that add or upgrade to a package with a known vulnerability above a severity you choose, and should warn on lesser findings. On a payments repo, also require the check to pass before merge and keep a written exception process.
What dependency review does
GitHub's documentation describes dependency review as a view of dependency changes and their security impact at every pull request. It shows which dependencies were added, removed or updated, along with release dates, how many projects use them, and vulnerability data. For pull requests that change manifests or lockfiles, it includes changes to indirect dependencies, which matters because transitive packages are where surprises hide.
The dependency review action goes further by enforcing it in a workflow. By default the check fails if it discovers any vulnerable packages, and a failed check blocks the merge when the repository owner requires it to pass. Organization owners can roll it out across repositories using rulesets that make the workflow required.
Decide your blocking policy
| Finding | Suggested action | Reason |
|---|---|---|
| Known vulnerability, high or critical, in a new package | Block | Do not add known problems |
| Known vulnerability in an upgrade that fixes an older one | Warn, review | Net improvement may be acceptable |
| Moderate or low severity | Warn | Track, do not stall delivery |
| New package from a source you have not reviewed | Warn and tag a code owner | Triggers the intake checklist |
| License outside your policy | Block | Cheaper to catch before merge |
The actions in the table are a suggestion, not a standard. The point is that the policy is written, so the team does not renegotiate it in every pull request.
Why blocking at the pull request is cheaper
The GitHub documentation makes the argument directly: alerts find vulnerabilities already in your dependencies, but it is better to avoid introducing problems than to fix them later. The OWASP vulnerable dependency guidance says similar: run automated analysis from the birth of a project, because adding it late can bring a huge amount of work and block progress.
Make it part of branch rules
- Enable the dependency graph, which makes dependency review available according to GitHub.
- Add the dependency review workflow to the repository, or require it organization wide.
- Mark the check as required in your ruleset so it blocks merging.
- Pair it with code owner review on lockfiles and manifests in payment services.
- Document the process for exceptions.
Note that the action is available on all public repositories, and on private repositories that have GitHub Code Security or GitHub Advanced Security enabled, so check your plan before you design around it.
Exceptions without chaos
Sometimes a vulnerable version has no fix, or the flaw is in a function your code never calls. OWASP says the decision to accept a risk should be taken by the chief risk officer, falling back to the security lead, on technical feedback from the development team. For a small company, name who that person is. Require a ticket reference, an expiry date for the exception, and an owner.
OWASP also advises scoping any ignore entry narrowly. An ignore should cover the specific advisory, not the whole dependency, because one package can have several vulnerabilities, each with its own identifier.
Avoid these traps
- A check that is optional becomes a check that is ignored.
- A policy that blocks on everything trains people to bypass it. Start with severity thresholds you can sustain.
- A lockfile change reviewed by nobody. The review check covers known issues, not intent, so human review still matters.
Where Safeguard fits
Safeguard's policies and gates apply to pull requests, and its SBOM and dependency scanning with reachability analysis helps separate flaws your code can reach from those it cannot. A free scan is available at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the failing check and see what information a reviewer gets before deciding.
Quick check
Does dependency review find vulnerabilities already in my project?
Its job is to check changes in a pull request. GitHub points to Dependabot alerts for vulnerabilities already present in your dependencies.
Should every finding block a merge?
No. Block on a severity you can sustain, warn on the rest, and write down the exception process.
Sources
- GitHub Docs, About dependency review
- OWASP Vulnerable Dependency Management Cheat Sheet
- GitHub Docs, Available rules for rulesets
Last reviewed: 19 October 2026.
