Block noncompliant dependencies before GitHub merges

How do I block noncompliant dependencies before merging on GitHub

Use GitHub branch protection or a ruleset to require a dependency review check before merge. The merge button stays blocked until that check passes, so dependency additions and version bumps are reviewed before they land. GitHub’s dependency review action is the standard way to surface those changes in pull requests.

The setup has two parts. First, add a workflow that runs dependency review on every pull request. Second, mark that workflow check as required on the branch or ruleset that protects your main line. GitHub says required status checks must pass before a pull request can be merged.

A minimal workflow looks like this, and it belongs in .github/workflows/dependency-review.yml:

```yaml name: Dependency Review on: pull_request: branches: ["main"]

permissions: contents: read pull-requests: read

jobs: review: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Dependency review uses: actions/dependency-review-action@v4 ```

GitHub documents the dependency review action as the tool that reports on dependency differences in a pull request, and the examples use versioned action references. The check runs in GitHub Actions, so it can be required like any other status check.

After the workflow exists, go to the protected branch or organization ruleset and require that check. GitHub’s branch protection settings let you require status checks before merging, and rulesets do the same at repository or organization level. A required check from the dependency review action is what turns review output into a merge gate.

The part people get wrong is relying on the workflow alone. A green check in Actions does nothing if nobody requires it. GitHub notes that status checks can be created by integrations or people with write access, so the real control is to require the expected check source in protection settings, not just to run the job.

If you need to block only specific dependency changes, configure the dependency review action to fail on the conditions you care about. GitHub’s documentation points to inlined options or a config file for the action, which lets you tune what counts as a failure instead of accepting every dependency change automatically.

For example, you can keep the gate on the pull request and review the output before merge. When a pull request adds or updates a dependency, the check shows the delta in the PR, and the branch cannot merge until the check passes. That gives reviewers a concrete list of dependency changes instead of asking them to inspect lockfiles by hand.

The inconvenient part is that this only works on the branch you protect. If your repository still allows direct pushes to the target branch, or if certain actors can bypass rules, those paths can skip the gate. GitHub’s branch protection settings include bypass and review-related options, so you need to review those permissions as part of the rollout.

A practical baseline is to protect main, require the dependency review check, require at least one approving review, and require status checks to be up to date before merging. GitHub documents these options together because they solve different parts of the same problem: code review, dependency review, and fresh validation.

If your team uses an organization, rulesets are easier to scale than repeating one-off branch rules. GitHub’s rulesets can target multiple repositories, and they can require status checks across the organization. That is the cleaner option when you want the same dependency gate everywhere.

You still need a human review step. Dependency review catches what changed in the pull request, but it does not decide whether every dependency is acceptable for your project. Teams usually pair the check with a review policy that says who can approve dependency changes and what kinds of upgrades are allowed. GitHub’s protected branch settings support required reviews alongside status checks.

If you are working in a repo with code owners, make those owners part of the merge rule. GitHub supports code owner approval in branch protection, so dependency changes can require the right reviewer instead of any reviewer. That matters when one package or ecosystem has its own maintainers.

A good test is simple: open a pull request that changes a dependency, then confirm the dependency review check fails or reports the change before merge. If the PR still merges, the gate is not actually enforced. The merge rule is only real when GitHub blocks the merge button until the check passes.

If you want to make the policy visible to contributors, link the repo README or contributor guide to the same rule and keep the enforcement in GitHub. DevConnect is free to use and keeps test coordination on your own terms, but the merge gate itself belongs in GitHub where the pull request is reviewed. https://devconnectplatform.com is useful for coordination, not for enforcement.

The safest pattern is: run dependency review on every pull request, require that check on the protected branch or ruleset, limit bypasses, and require review from the people who own the dependency surface. That is the difference between a report and a block.

FAQ

Can I block dependency changes without using GitHub Actions Yes, but the cleanest gate on GitHub is still a required status check. GitHub can require checks from a workflow, an external CI system, or a commit status, but the branch or ruleset must explicitly require that signal before merge.

Does dependency review stop every risky package No. It reviews dependency changes in the pull request and lets you enforce a merge gate, but your policy still decides what counts as noncompliant. The check is the mechanism, not the policy itself.

Can someone bypass the block Only if your rules allow it. GitHub branch protection and rulesets both include bypass-related permissions, so you should review who can push, dismiss reviews, or bypass requirements. If those permissions are broad, the gate is weaker.

Should I protect one branch or use a ruleset Protect one branch if you have a single repo and a single release path. Use a ruleset if you want the same dependency gate across multiple repositories or branch patterns. GitHub documents rulesets for organization-wide control.

What should I check first when the gate does not fire Check that the workflow ran on the pull request, that the exact check name is required in branch protection or the ruleset, and that the target branch is actually protected. If any of those are missing, the merge can still go through.