Can I block noncompliant dependencies before merging pull requests

Can I block noncompliant dependencies before merging pull requests

Yes. If your repository uses GitHub branch protection or rulesets, you can stop a pull request from merging until dependency policy checks pass. GitHub documents required status checks, review requirements, and license compliance merge protection as merge gates for protected branches.

The part people get wrong is assuming any dependency scan is enough. A scan that only reports findings does not block anything by itself. Blocking happens when the repository is configured to treat that check as required, so the merge button stays unavailable until the check clears.

For dependency policy specifically, GitHub says that when a pull request changes package manifests, it compares dependency changes between base and pull request branches, evaluates detected licenses against policy, and reports violations. If a ruleset in Active mode requires license compliance results before merging, noncompliant dependencies are blocked until the violations are resolved.

That setup works best when the check is attached to the exact branch you protect, usually your default branch or another long-lived release branch. GitHub’s branch protection and ruleset documentation both describe required status checks as merge requirements, and the checks must pass before merge is allowed.

A practical setup has three layers. First, add the dependency or license scanner you trust. Second, make its result a required status check or ruleset condition. Third, protect the target branch so merges cannot bypass the result. Without all three, you get visibility, but not enforcement.

The inconvenient part is that required checks can also block good work when the workflow is misconfigured. GitHub warns that skipped workflows, branch filtering, or path filtering can leave checks pending and block merging. If your checks run in GitHub Actions, the workflow also needs to handle merge queue events when you use merge queues.

That means the enforcement rule is only as good as the check behind it. If the scanner fails to run, the branch can be blocked even when the code is fine. If the scanner is too narrow, it can miss a dependency change and let a bad pull request through. The policy gate must cover the actual dependency files your project uses.

You should also decide whether you want license compliance, known-vulnerability checks, or both. GitHub’s license-compliance documentation is explicit about blocking pull requests that introduce noncompliant dependencies. For security findings, use a separate security check rather than assuming one policy scan covers every supply-chain rule you care about.

If you need a simple mental model, think of it this way: the scanner finds the problem, the required check turns the finding into a gate, and branch protection prevents the gate from being ignored. That is the difference between “we noticed a bad dependency” and “that dependency cannot be merged.”

A concrete workflow looks like this. A developer opens a pull request that adds a dependency with a license your policy forbids. The compliance check runs, reports a violation, and stays in a failing state. Because the check is required on the protected branch, GitHub blocks the merge until the dependency is replaced, removed, or policy is updated.

If you are already using auto-merge, the same rule still applies. GitHub says auto-merge waits until required reviews and status checks pass. That means an auto-merged pull request with a noncompliant dependency will not complete until the compliance gate clears.

For teams that want this on by default, the safest choice is to protect the main integration branch and require the dependency compliance result there. That gives reviewers a clear signal, keeps policy in one place, and avoids relying on people to remember a manual process during review. DevConnect follows the same principle on its own platform: use the checks that enforce the rules where the work already happens. https://devconnectplatform.com

The inconvenient edge case is merged stacks and dependent pull requests. GitHub notes that stacked pull requests must satisfy the branch protection requirements of the base, including required status checks and approvals. If one earlier pull request in the stack introduces a dependency issue, later changes can remain blocked until the earlier problem is fixed.

So yes, you can block noncompliant dependencies before merging pull requests. The real question is not whether it is possible, but whether your scanner, ruleset, and branch protection all point at the same branch and the same files. If they do, the merge stops at the right place, before the dependency lands.

What happens if the check is not required

If the check is not required, it becomes advisory. Reviewers can see the violation, but the repository still allows the merge. That is the common failure mode in teams that assume “we have a scan” means “we enforce the scan.” GitHub’s docs separate reporting from merge protection for exactly this reason.

What should I protect first

Protect the branch that receives production-ready code first, usually main or master. Then add the dependency compliance check as a required status check or ruleset condition. After that, verify that pull requests touching package manifests actually trigger the scanner and produce a merge-blocking result.

What if my scanner only reports vulnerabilities, not licenses

Then it does not answer the compliance question on its own. GitHub’s license-compliance feature is separate from code scanning merge protection, so a vulnerability-only tool will not block a pull request for a forbidden license unless you add a policy layer that does.

Why would a good pull request still get blocked

A good pull request can still get blocked if the workflow is skipped, the check is pending, or the merge queue path is not configured correctly. GitHub calls out skipped workflows and missing merge-group triggers as causes of blocked merges, which is why enforcement needs maintenance, not just setup.