Merge Policy

Merge Policy lets your security team decide what’s safe to ship and have Corridor enforce it automatically. You choose which finding severities should stop a merge as a team-wide standard, and Corridor holds any pull request with open findings at those severities—across every repository—until they’re resolved or explicitly accepted. Enforcement lives inside the GitHub workflow your developers already use.

​

Prerequisites

• Pull Request Reviews enabled for your team
• GitHub connected to Corridor
• Permission to edit branch protection or rulesets on the repository you want to protect

​

How it works

Your merge policy is enforced by the Corridor Review check, which appears as a required status check on the pull request—the same place developers already look before merging:

• Passing — no open findings at your policy’s severities.
• Failing — one or more findings need attention. When the check is required in branch protection, the merge is held until they’re resolved or accepted.

You decide what the policy enforces: choose which severities gate a merge (for example, Critical and High), while lower-severity findings are surfaced for visibility without holding the merge.

​

Setting your merge policy

There are two steps: set your policy in Corridor, then require the check in GitHub. Both are required—Corridor reports the pass/fail signal, and branch protection is what turns that signal into enforcement.

​

1. Choose your policy in Corridor

Go to Governance → Merge Policy and:

1. Ensure Pull Request Reviews are enabled for your team.
2. Under Your merge policy, select the finding severities your team requires resolved before a pull request can merge (for example, Critical and High). Leaving every severity unselected turns enforcement off.
3. Ensure Leave Comments on Pull Requests is on. Corridor posts each finding as an inline comment, and that comment thread is where developers resolve a held pull request (reply false positive or unblock).

Findings at severities you leave unselected are still surfaced on the pull request for visibility without holding the merge. The policy is a team-wide standard—it applies to every project on the team and can’t be overridden per project.

​

2. Require the check in GitHub

This is the step that enforces the policy—on its own, the Corridor Review check reports pass/fail but does not prevent merges. Without step 2, the Corridor Review check still runs and reports pass/fail on every pull request, but GitHub won’t prevent merges—branch protection is what turns the signal into enforcement.

​

Resolving a held pull request

Developers can bring a pull request into line with your policy in whatever way fits the situation, all from the pull request:

• Fix the code — push a fix and Corridor automatically re-validates the finding and clears the check once it’s resolved. No manual step required.
• Mark a false positive — reply false positive on the finding’s inline comment to dismiss it, with the decision recorded.
• Accept the risk (unblock) — reply unblock to override a specific finding when your team decides to proceed.
• Adjust from the dashboard — security teams can change a finding’s severity or resolve it centrally, and the check updates automatically.

See Replying to Corridor’s comments for more on the reply workflow.

​

Reviewing what’s held for review

The Governance → Merge Policy page gives your security team a single view of every pull request currently held by policy. You can see which projects are accumulating held pull requests, how long each has been waiting, and how many findings are open on it. Filter by severity or project, or open any pull request directly on GitHub.

​

Availability

Merge Policy works with GitHub today. GitLab support is on the roadmap.

​

Next steps