> ## Documentation Index
> Fetch the complete documentation index at: https://docs.corridor.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Merge Policy

> Set a team-wide security merge policy so Corridor holds any pull request with open findings at your chosen severities until they're resolved or accepted.

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](/features/pr-reviews) enabled for your team
* GitHub [connected](/onboarding/connecting-github) 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](/features/pr-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.

<Tabs>
  <Tab title="Branch protection">
    1. Go to repository **Settings → Branches → Add branch protection rule** (or edit an existing rule).
    2. Set the **Branch name pattern** to your protected branch (for example, `main`).
    3. Enable **Require status checks to pass before merging**.
    4. In the search box that appears, find and select **Corridor Review**.
    5. Save changes.
  </Tab>

  <Tab title="Rulesets">
    1. Go to **Settings → Rules → Rulesets → New branch ruleset** and target your branch(es).
    2. Under **Require status checks to pass**, click **Add checks**, search **Corridor Review**, and add it.
    3. Set the ruleset to **Active** and save.
  </Tab>
</Tabs>

<Tip>
  GitHub only lists a status check once it has run at least once (recently). If **Corridor Review** doesn't appear in the search, open or update a pull request so the check runs, then it'll be selectable.
</Tip>

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](/features/pr-reviews#replying-to-corridors-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

<CardGroup cols={2}>
  <Card title="PR Reviews" icon="code-pull-request" href="/features/pr-reviews">
    How Corridor reviews pull requests and how to reply to findings
  </Card>

  <Card title="Findings" icon="magnifying-glass" href="/features/findings">
    Track and manage security findings
  </Card>
</CardGroup>