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

# 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.

You can create two types of blocking rules:

* **Code Vulnerability Rules**: Block PRs based on code security issues found by SAST scanning
* **Dependency Vulnerability Rules**: Block PRs based on vulnerable dependencies found by SCA scanning

### 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

<AccordionGroup>
  <Accordion title="Enforce Coding Standards" icon="shield-check">
    Define rules based on Common Weakness Enumerations (CWEs) to block pull requests that introduce specific types of vulnerabilities or code quality issues.
  </Accordion>

  <Accordion title="Customize Urgency Levels" icon="signal">
    Assign urgency levels (e.g., critical, high, medium, low) to different types of issues, allowing you to prioritize and handle them accordingly.
  </Accordion>

  <Accordion title="Filter Dependencies by CVSS" icon="gauge">
    For dependency vulnerability rules, define an inclusive CVSS score range to block vulnerable dependencies based on their CVSS score.
  </Accordion>

  <Accordion title="Project and Tag Scoped Rules" icon="folder-tree">
    Apply blocking rules to specific projects, project tags, or across your entire organization, giving you granular control over which projects are subject to which rules.
  </Accordion>

  <Accordion title="Rule Management" icon="gear">
    Easily create, edit, and delete blocking rules through a user-friendly interface, ensuring your rules stay up-to-date with your evolving requirements.
  </Accordion>

  <Accordion title="Rule Activation/Deactivation" icon="toggle-on">
    Toggle the status of blocking rules to temporarily enable or disable them as needed, without losing their configurations.
  </Accordion>
</AccordionGroup>

## Rule Types

Blocking rules support two distinct types to provide comprehensive security coverage:

<CardGroup cols={2}>
  <Card title="Code Vulnerability" icon="code">
    Blocks pull requests based on **code security issues** found by static application security testing (SAST).

    Configure by:

    * Selecting specific CWE (Common Weakness Enumeration) categories
    * Setting urgency/severity levels

    Use this to prevent issues like SQL injection, XSS, insecure cryptography, and other code-level vulnerabilities.
  </Card>

  <Card title="Dependency Vulnerability" icon="box">
    Blocks pull requests based on **vulnerable dependencies** found by software composition analysis (SCA).

    Configure by:

    * Setting urgency/severity levels (Critical, High, Medium, Low)
    * Or setting an inclusive CVSS score range from 0.0 to 10.0

    Use this to prevent the introduction of packages with known security vulnerabilities, ensuring your supply chain remains secure.
  </Card>
</CardGroup>

## How it Works with GitHub

<Info>
  **Prerequisite** You must have installed and configured the [Corgea GitHub App](github) with appropriate repository permissions.
</Info>

<Steps>
  <Step title="Pull Request Submission">
    Developer submits a pull request with code changes
  </Step>

  <Step title="Automated Analysis">
    System analyzes code changes against active blocking rules
  </Step>

  <Step title="Rule Validation">
    If violations are found, pull request is automatically blocked

    <Frame>
      <img src="https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/blocking_rules_pr_blocked.png?fit=max&auto=format&n=uxLuQR4653lM43Tj&q=85&s=39013c8f8163f96d432b0f9bd4abbc05" style={{ borderRadius: '0.5rem' }} width="2776" height="1034" data-path="images/blocking_rules_pr_blocked.png" />
    </Frame>
  </Step>

  <Step title="Developer Notification">
    Developer receives detailed notification about rule violations

    <Frame>
      <img src="https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/blocking_rules_pr_details.png?fit=max&auto=format&n=uxLuQR4653lM43Tj&q=85&s=4ac0e073341d12a425db9a4412e55b3e" style={{ borderRadius: '0.5rem' }} width="3078" height="1834" data-path="images/blocking_rules_pr_details.png" />
    </Frame>
  </Step>

  <Step title="Resolution">
    Developer must fix violations and mark them as Fixed, or mark them as False Positive or Accepted Risk before merge is allowed
  </Step>
</Steps>

## How it Works with Azure DevOps

<Info>
  **Prerequisite** Make sure the [Azure DevOps integration](azure_devops) with Corgea is configured and you have the necessary permissions.
</Info>

<Steps>
  <Step title="Pull Request Submission">
    A developer submits a pull request with code changes in Azure DevOps.
  </Step>

  <Step title="Automated Analysis">
    The system evaluates the code changes against the active blocking rules set in Corgea.
  </Step>

  <Step title="Rule Validation">
    If violations are found, the pull request is automatically blocked.

    <Frame>
      <img src="https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/azure_blocking_rules_pr_blocked.png?fit=max&auto=format&n=uxLuQR4653lM43Tj&q=85&s=a85aa91d3cea8d9572197b863bafa4e4" style={{ borderRadius: '0.5rem' }} width="966" height="512" data-path="images/azure_blocking_rules_pr_blocked.png" />
    </Frame>

    Developer cannot merge the PR until it is resolved.

    <Frame>
      <img src="https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/azure-devops_merging_blocked.png?fit=max&auto=format&n=uxLuQR4653lM43Tj&q=85&s=1ecb01eb911476a19b0265a3b56dad72" style={{ borderRadius: '0.5rem' }} width="2900" height="2630" data-path="images/azure-devops_merging_blocked.png" />
    </Frame>
  </Step>

  <Step title="Developer Notification">
    The developer receives a link to view detailed information about the failed issues on the Corgea Scan page.

    <Frame>
      <img src="https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/azure_see_details_of_issues.png?fit=max&auto=format&n=uxLuQR4653lM43Tj&q=85&s=e5e94b8c2fec2b7abab7eb76a37533b1" style={{ borderRadius: '0.5rem' }} width="2696" height="1556" data-path="images/azure_see_details_of_issues.png" />
    </Frame>
  </Step>

  <Step title="Resolution">
    The developer must resolve the violations by fixing them or marking them as False Positive or Accepted Risk before the merge can proceed.
  </Step>
</Steps>

## Usage Guide

### Creating a New Blocking Rule

<Steps>
  <Step title="Initiate Creation">
    Click the "Add Blocking Rule" button
  </Step>

  <Step title="Choose Rule Type">
    Select the type of blocking rule:

    * **Code Vulnerability**: Block pull requests based on code security issues (SAST findings)
    * **Dependency Vulnerability**: Block pull requests based on vulnerable dependencies (SCA findings)

    <Frame>
      <img src="https://mintcdn.com/corgea/5RdbtGRSeHorS3ia/images/blocking_rule_create.png?fit=max&auto=format&n=5RdbtGRSeHorS3ia&q=85&s=30d79ec3c8001ced6485f58022aa3606" style={{ borderRadius: '0.5rem' }} width="1656" height="1640" data-path="images/blocking_rule_create.png" />
    </Frame>
  </Step>

  <Step title="Basic Information">
    Enter rule name and description
  </Step>

  <Step title="Configure Settings">
    For **Code Vulnerability** rules: 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

    For **Dependency Vulnerability** rules: Choose whether to filter by severity or CVSS score. Select urgency levels (Critical, High, Medium, or Low), or enter a minimum and maximum CVSS score from 0.0 to 10.0 to block vulnerable dependencies within that inclusive range.
  </Step>

  <Step title="Set Scope">
    Choose applicable projects and/or project tags (optional). A rule applies when a project is selected directly or has any selected tag. If no projects or tags are selected, the rule applies to all projects.
  </Step>

  <Step title="Save">
    Review and click "Create"
  </Step>
</Steps>

### Managing Existing Rules

Use search to find rules by name or settings, or use the project tag filter to show rules that apply to projects with a specific tag.

<Tabs>
  <Tab title="Edit Rule">
    1. Locate rule in table
    2. Click "Edit" button
    3. Modify settings as needed
    4. Click "Update" to save
  </Tab>

  <Tab title="Toggle Status">
    1. Find rule in table
    2. Click "Toggle Status"
    3. Confirm status change
  </Tab>

  <Tab title="View Details">
    1. Click on rule name
    2. Review comprehensive information
    3. Close modal when done
  </Tab>
</Tabs>

### 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="https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/blocking_rules_scan_details.png?fit=max&auto=format&n=uxLuQR4653lM43Tj&q=85&s=a132f7927273e0eaf8bdb84065bbcbf4" style={{ borderRadius: '0.5rem' }} width="1518" height="1082" data-path="images/blocking_rules_scan_details.png" />
</Frame>

2. For individual issues, you can see which blocking rules were triggered in the issue details:

<Frame>
  <img src="https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/blocking_rule_issue_details.png?fit=max&auto=format&n=uxLuQR4653lM43Tj&q=85&s=433dd74d99f714b953608a1e59ac973a" style={{ borderRadius: '0.5rem' }} width="3072" height="1124" data-path="images/blocking_rule_issue_details.png" />
</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

<AccordionGroup>
  <Accordion title="Blocking Insecure Cryptography" icon="lock">
    **Rule Type:** Code Vulnerability

    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.
  </Accordion>

  <Accordion title="Enforcing Code Quality" icon="code">
    **Rule Type:** Code Vulnerability

    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.
  </Accordion>

  <Accordion title="Blocking Critical Dependency Vulnerabilities" icon="box">
    **Rule Type:** Dependency Vulnerability

    Create a rule with "Critical" and "High" urgency levels selected to automatically block any pull request that introduces dependencies with critical or high-severity vulnerabilities. This ensures your supply chain remains secure and prevents known vulnerable packages from entering your codebase.
  </Accordion>

  <Accordion title="Blocking Dependencies by CVSS Range" icon="gauge">
    **Rule Type:** Dependency Vulnerability

    Create a rule that filters by CVSS score, such as 7.0 to 10.0, to block pull requests that introduce vulnerable dependencies within that score range.
  </Accordion>
</AccordionGroup>

## Best Practices

<Card title="Implementation Tips" icon="lightbulb">
  * Start with essential rules and gradually expand
  * For **Dependency Vulnerability rules**, begin with Critical severity only or a focused CVSS range, then expand as your team adjusts
  * For **Code Vulnerability rules**, focus on the most impactful CWEs first (e.g., injection flaws, authentication issues)
  * Regular review and updates
  * Clear documentation and team training
  * Encourage feedback and collaboration
  * Strategic use of urgency levels
  * Consider project tags when the same rule should cover a group of related projects
</Card>

## Troubleshooting

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

<AccordionGroup>
  <Accordion title="Common Issues" icon="bug">
    * Unexpected blocking behavior
    * Rule targeting issues
    * Project scope problems
  </Accordion>

  <Accordion title="Resolution Steps" icon="wrench">
    * Check rule configurations
    * Verify CWE targeting
    * Confirm project settings
    * Contact support if needed
  </Accordion>
</AccordionGroup>