Skip to content

Latest commit

 

History

History
201 lines (169 loc) · 7.24 KB

blocking_rules.mdx

File metadata and controls

201 lines (169 loc) · 7.24 KB
title description
Blocking Rules
Blocking rules help enforce security and quality standards by preventing non-compliant code from being merged.

Overview

What it Does

Blocking rules are powerful guardrails that allow you to define specific conditions under which pull requests should be blocked from being merged. This helps ensure that your codebase adheres to your organization's security and quality standards by preventing potentially risky or non-compliant code changes from being merged.

Who it's For

Blocking rules are primarily designed for:

  • Development teams
  • Project managers
  • Security professionals

This feature is particularly useful for organizations with strict compliance requirements or those working on mission-critical applications where code quality and security are paramount.

Key Features and Benefits

Define rules based on Common Weakness Enumerations (CWEs) to block pull requests that introduce specific types of vulnerabilities or code quality issues. Assign urgency levels (e.g., critical, high, medium, low) to different types of issues, allowing you to prioritize and handle them accordingly. Apply blocking rules to specific projects or across your entire organization, giving you granular control over which projects are subject to which rules. Easily create, edit, and delete blocking rules through a user-friendly interface, ensuring your rules stay up-to-date with your evolving requirements. Toggle the status of blocking rules to temporarily enable or disable them as needed, without losing their configurations.

How it Works with GitHub

**Prerequisite** You must have installed and configured the [Corgea GitHub App](github) with appropriate repository permissions. Developer submits a pull request with code changes System analyzes code changes against active blocking rules If violations are found, pull request is automatically blocked

Developer receives detailed notification about rule violations

Developer must fix violations and mark them as Fixed, or mark them as False Positive or Accepted Risk before merge is allowed

How it Works with Azure DevOps

**Prerequisite** Make sure the [Azure DevOps integration](azure_devops) with Corgea is configured and you have the necessary permissions. A developer submits a pull request with code changes in Azure DevOps. The system evaluates the code changes against the active blocking rules set in Corgea. If violations are found, the pull request is automatically blocked.

The developer receives a link to view detailed information about the failed issues on the Corgea Scan page.

The developer must resolve the violations by fixing them or marking them as False Positive or Accepted Risk before the merge can proceed.

Usage Guide

Creating a New Blocking Rule

Click the "Add Blocking Rule" button Enter rule name and description

Select urgency levels (Critical, High, Medium, or Low) and/or target CWEs - at least one of these must be defined for the rule to be valid Choose applicable projects (optional) Review and click "Create"

Managing Existing Rules

1. Locate rule in table 2. Click "Edit" button 3. Modify settings as needed 4. Click "Update" to save 1. Find rule in table 2. Click "Toggle Status" 3. Confirm status change 1. Click on rule name 2. Review comprehensive information 3. Close modal when done

Viewing Rules on scans

You can view blocking rules that apply to your scans in two places:

1. On the scan details page, you'll see a "Blocking Rules" section showing all rules that were evaluated:
<Frame>
  <img src="/images/blocking_rules_scan_details.png" style={{ borderRadius: '0.5rem' }} />
</Frame>

2. For individual issues, you can see which blocking rules were triggered in the issue details:
<Frame>
  <img src="/images/blocking_rule_issue_details.png" style={{ borderRadius: '0.5rem' }} />
</Frame>

This makes it easy to understand which rules are affecting your scans and specific issues, helping you identify why certain changes may be blocked.

Examples

Create a rule targeting CWE-326 (Inadequate Encryption Strength) and CWE-327 (Use of a Broken or Risky Cryptographic Algorithm) with "Critical" urgency to prevent weak encryption usage. Set up a rule for CWE-398 (Indicator of Poor Code Quality) and CWE-477 (Use of Obsolete Functions) with "Medium" urgency to maintain code standards.

Best Practices

- Start with essential rules and gradually expand - Regular review and updates - Clear documentation and team training - Encourage feedback and collaboration - Strategic use of urgency levels

Troubleshooting

If a pull request is unexpectedly blocked, verify the active rules and their configurations first.

- Unexpected blocking behavior - Rule targeting issues - Project scope problems - Check rule configurations - Verify CWE targeting - Confirm project settings - Contact support if needed