Skip to content

Configuring Alerts & Blocks

The PR scanning configuration controls what happens when findings are detected in a pull request. You define which severities trigger informational alerts, which severities block the PR, and which scanners run.

The Configuration Modal

To configure PR scanning for a repository:

  1. Navigate to PR Scanning from the left sidebar
  2. Find the repository you want to configure
  3. Click the Configure button (gear icon) on the repository's row
  4. The configuration modal opens

The configuration modal has three sections:

Alert Severities

Select which severity levels should generate alerts — findings that are reported in the PR comment but do not block the merge:

  • Critical
  • Medium
  • Low
  • Informational

Alert vs. Block

A severity level should be in either the alert list or the block list, not both. If a severity is in the block list, it will be reported as a blocking finding. If it is in neither list, findings at that severity are silently ignored.

Block Severities

Select which severity levels should block the PR — findings that cause the check run to fail:

  • Critical
  • High
  • Medium
  • Low

When a finding matches a block severity:

  1. The check run status is set to failure
  2. The finding is highlighted in the PR comment with a block indicator
  3. If branch protection requires the check to pass, the PR cannot be merged

Scanner Selection

Choose which scanners run during PR scans:

Scanner Recommended For
OpenGrep Fast SAST coverage — good default for PR scanning
Semgrep Deep SAST with framework-specific rules
Trivy Dependency vulnerability checks
Grype Fast CVE detection for dependencies
Gitleaks Catching secrets before they reach the default branch

Scanner Selection for PR Scanning

For PR scanning, speed matters — developers are waiting for results. We recommend:

  • OpenGrep as the primary SAST scanner (faster than Semgrep for PR use cases)
  • Gitleaks to catch secrets in every PR
  • Trivy if your team frequently updates dependencies

Avoid running all five scanners on every PR unless scan times are acceptable for your team.

Example Configurations

Conservative (Minimal Blocking)

Best for teams just starting with PR scanning who want visibility without disruption:

Setting Value
Block severities Critical only
Alert severities High, Medium
Scanners OpenGrep

Start Here

This configuration blocks only the most severe issues while building developer awareness of security findings. Expand blocking as your team builds confidence.

A good default for most teams:

Setting Value
Block severities Critical, High
Alert severities Medium, Low
Scanners OpenGrep, Gitleaks

This blocks critical and high findings, alerts on medium and low, and catches both code vulnerabilities and secrets.

Strict (Maximum Security)

For security-critical applications (payment processing, authentication services, healthcare):

Setting Value
Block severities Critical, High, Medium
Alert severities Low
Scanners OpenGrep, Semgrep, Trivy, Gitleaks

Impact on Developer Velocity

Strict configurations significantly increase the chance of PRs being blocked. Ensure your team has a process for handling blocked PRs (security team review, exception requests, etc.) before enabling this.

Secrets-Only

For teams that only want to prevent secrets from being committed:

Setting Value
Block severities Critical, High, Medium, Low
Alert severities (none)
Scanners Gitleaks only

This blocks all secret findings regardless of severity, while ignoring code and dependency vulnerabilities in PR scanning (those can be caught by scheduled scans instead).

Dependency-Focused

For teams primarily concerned about vulnerable dependencies:

Setting Value
Block severities Critical
Alert severities High, Medium
Scanners Trivy, Grype

Severity Mapping

Understanding how scanner outputs map to Mayo ASPM severity levels:

Mayo ASPM Severity CVSS Score Range Typical Findings
Critical 9.0 - 10.0 Remote code execution, authentication bypass, known exploited CVEs
High 7.0 - 8.9 SQL injection, XSS, command injection, high-severity CVEs
Medium 4.0 - 6.9 Information disclosure, CSRF, medium-severity CVEs
Low 0.1 - 3.9 Best practice violations, informational findings, low-severity CVEs

Saving and Applying Configuration

After adjusting settings in the modal:

  1. Click Save to apply the configuration
  2. The new settings take effect immediately for all future PR scans
  3. Existing open PRs are not retroactively rescanned — the new configuration applies to the next push or PR event

Configuration History

Configuration changes are logged. You can see who last modified the PR scanning configuration and when by hovering over the repository's row in the PR Scanning table.

Per-Repository vs. Organization Defaults

Each repository can have its own unique PR scanning configuration. However, when you first enable PR scanning, the organization default is applied.

To change the organization default:

  1. Navigate to Settings > PR Scanning Defaults (available to organization admins)
  2. Set your preferred alert severities, block severities, and scanner selection
  3. Save — these defaults apply to all newly enabled repositories going forward

Existing repository configurations are not affected when you change the organization default.

Using OPA Advanced Mode

For more sophisticated control, switch from simple mode to OPA advanced mode:

  1. In the configuration modal, toggle Mode from Simple to OPA
  2. Select or create an OPA policy of kind pr_scan
  3. The policy receives finding data as input and returns block/alert decisions

Example OPA policy:

package mayo.pr_scan

# Block critical and high findings
block {
    input.finding.severity in ["critical", "high"]
}

# But allow known false positives
allow {
    input.finding.rule_id == "generic-api-key"
    endswith(input.finding.file_path, ".example.env")
}

# Alert on medium findings in production code
alert {
    input.finding.severity == "medium"
    not startswith(input.finding.file_path, "test/")
}

See PR Scan Policy for full details on writing PR scan policies.

Next Steps