On GitHub, you can run the dependency review action as a required workflow through repository rulesets set at the organization level. Pull requests then cannot merge until the workflow passes, with no per repo setup by each team.
The two pieces
Dependency review shows what changed in dependencies for a pull request. GitHub's documentation says that for pull requests touching manifests or lock files, it displays changes including indirect dependencies, and tells you whether added or updated dependencies have known vulnerabilities. It also surfaces license, age and dependent information.
The dependency review action runs that check in GitHub Actions. The documentation says it fails if it finds vulnerable packages, and that a failed check blocks merging when the repository owner requires the check to pass. It uses the dependency review REST API, which returns the diff between a base and head commit with vulnerability data.
Rulesets are the enforcement layer. A ruleset is a named list of rules applied to a repository or, on Team and Enterprise plans, to multiple repositories in an organization. GitHub's docs state limits of 75 rulesets per repository and 75 organization wide rulesets, and let you allow specific roles or teams to bypass.
Steps
- Confirm your plan and repo types support dependency review. The documentation lists public repositories and organization owned repositories with GitHub Code Security enabled.
- Add a workflow file that runs the action on pull requests.
- Create an organization ruleset targeting the repositories you choose.
- Set the workflow as required in the ruleset.
- Start in a mode that reports before it blocks, if your setup allows, and review the results for a week.
- Define the bypass list, keep it short, and review who is on it.
Decide what the check should fail on
| Setting | Effect | Use when |
|---|---|---|
| Fail on any known vulnerability | Strict, many blocks | New services with few dependencies |
| Fail on high severity or above | Moderate | Most mature teams |
| Warn only | No blocking | First two weeks of rollout |
Check the action's own documentation for the exact option names before you copy settings, since they can change between releases.
What it catches and misses
It checks newly introduced dependency changes against known vulnerability data. It does not tell you whether the vulnerable code is reachable, and it does not look at issues in dependencies already merged. For the longer discussion see what dependency review catches and misses.
Avoiding a revolt
Required checks that block unexpectedly cost trust. Announce the date, publish the policy, give teams a path to request an exception with an expiry, and make sure the failure message says what to do next.
Where Safeguard fits
Safeguard provides policies, gates and guardrails for pull requests, with reachability analysis to separate reachable findings from noise, and continuous monitoring after merge. Try a free scan at gold.safeguard.sh/scan.
Try it yourself
Open the gate demo and see what a blocked pull request looks like to the developer, and what information they need to unblock it.
Click through it at your own pace, or open it full screen.
Quick check
Does a required workflow need each team to configure it?
No. GitHub's docs describe setting the action as a required workflow in an organization ruleset so it applies across the repositories you target.
Can someone bypass a ruleset?
Yes, if you allow specific roles or teams to bypass it. Keep that list short and reviewed.
Sources
Last reviewed: 19 October 2026.
