Corridor’s Pull Request (PR) review feature acts as an automated security reviewer for your code changes. Whenever you open or update a PR, Corridor analyzes the diff for potential security issues and provides feedback directly in the PR.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.
Developer workflow
Treat Corridor’s comments like those from a human reviewer specialized in security:- Understand the issue: Read the explanation and remediation guidance
- Push a fix: Push additional commits to address the problem. Corridor will re-check the PR on the new commit
- Handle false positives: If you believe it’s a false positive, mark it as such with feedback. This helps Corridor learn and helps the security team adjust guardrails
Configuration
PR review settings can be configured at two scopes:- Team-wide defaults apply to every project on the team. Configure them on the PR Reviews page → Configure (top right corner).
- Per-project overrides apply to a single project and take precedence over the team default. Configure them on the project page → Settings. See Project Settings.
Available settings
The table below applies to both team-wide defaults and per-project overrides, except where noted.| Setting | Description |
|---|---|
| Enable Pull Request Reviews | Automatically review pull requests for security vulnerabilities |
| Block PRs with Security Findings | Prevent merging pull requests that contain security vulnerabilities (blocks can still be overridden in GitHub). Corridor Team only. Team-wide setting |
| Review Verbosity Mode | Control how inclusive the PR reviewer is when flagging potential security issues. Standard review mode provides a balanced approach between catching vulnerabilities and minimizing false positives |
| Leave Comments on Pull Requests | Post review comments directly on GitHub PRs |
| Disable Comments for Specific Repos | PRs from selected repositories will still be reviewed but comments won’t be posted. Team-wide setting—to disable commenting for a single project, turn off Leave Comments on Pull Requests in that project’s settings instead |
Advanced settings
| Setting | Description |
|---|---|
| Enable Draft PR Reviews | Review pull requests that are marked as draft |
| GitHub Label Filter | Optionally restrict review comments to PRs with a specific label |
| Comment When No Issues Found | Leave a comment even when no vulnerabilities are detected |
| Minimum Severity to Comment On | Only post PR comments for findings at or above the selected severity level (Medium, High, or Critical). Defaults to all issues |
| Enable Threat Modeling | Include threat model analysis with risk level and security considerations on all PRs |
How it works
When a pull request is opened or updated:- Webhook trigger: GitHub sends a webhook to Corridor
- Diff analysis: Corridor analyzes only the changed code, understanding context from the broader codebase
- Security review: The changes are evaluated against security best practices, known vulnerability patterns, and your guardrails
- Review posted: Findings appear directly on the PR with inline comments
- Corridor Review check: GitHub shows a Corridor Review check on your pull request. It moves from Queued to In progress while Corridor reviews your changes, and to Success when the review is finished. The check does not block merging on its own. Click Details to open this review in the Corridor dashboard.
Review limits
| Tier | PR Reviews |
|---|---|
| Pro | 100/month |
| Team | 100/dev/month |
| Enterprise | Unlimited |
Developer count is based on unique developers interacting with Corridor—IDE users, dashboard users, and PR authors—in the given month.
Next steps
Findings
Track and manage security findings
Guardrails
Configure real-time security guardrails