Pull Requests Without Required Approvals

This compliance check detects pull requests that were merged without the required number of code review approvals. Code review is a critical control for preventing unauthorized or problematic changes from reaching production.

What It Detects

Dike counts the number of approved reviews on a merged PR and compares it against your configured threshold. If the approval count falls below the requirement, a violation is created.

Scenarios that trigger violations:

• PR merged with 0 approvals when 1+ required
• PR merged with 1 approval when 2+ required
• Self-approved PRs (author approves their own PR)

Examples of compliant PRs:

• PR with 2 approvals when 2 required
• PR with 3 approvals when 1 required
• PR reviewed and approved by authorized reviewers

The check uses GitHub's review API to count reviews with APPROVED status.

Why It Matters for SOC2

Code review is fundamental to SOC2 change management requirements:

• CC6.1 - Separation of Duties: Code review ensures someone other than the author validates changes, preventing a single individual from introducing unauthorized modifications.
• CC6.6 - Change Authorization: Reviews represent formal authorization from qualified personnel before code reaches production.
• CC6.7 - Segregation of Testing and Production: Reviewers verify that changes are appropriate for production deployment.
• CC8.1 - Quality Assurance: Reviews catch bugs, security issues, and design problems before they affect users.

Many SOC2 auditors specifically look for evidence of code review processes. This check provides that evidence automatically.

How to Resolve Violations

Immediate Resolution

1. Post-merge review: Request a code review after the fact and document it in the Jira issue.

2. Create remediation ticket: Document why the merge happened without approval and any additional validation performed.

3. Acknowledge with justification: If the merge was an authorized emergency:

   • Document the emergency in your incident tracking
   • Add acknowledgment explaining the circumstances
   • Schedule post-incident review

Preventive Measures

• Branch protection rules: Configure GitHub to require approvals before merging:

  Settings → Branches → Branch protection rules
  ✓ Require a pull request before merging
  ✓ Require approvals: 2
  ✓ Dismiss stale pull request approvals when new commits are pushed

• Prevent admin bypass: Don't allow repository admins to merge without reviews.

• CODEOWNERS file: Require approval from specific team members for critical paths:

  # .github/CODEOWNERS
  /src/auth/*    @security-team
  /src/payment/* @fintech-team @security-team

• Define review SLAs: Set expectations for review turnaround to reduce pressure to merge without approval.

Configuration Options

Rule Configuration

name: PR merged without required approvals
trigger: pr_merged
status: enabled
priority: high
conditions:
  - type: approvals
    operator: less-than
    value: 2
actions:
  - type: create-violation
    severity: high
branchPatterns: []

Configurable Parameters

Parameter	Description	Default
value	Minimum approval count required	2
operator	Comparison: less-than, equals, greater-than	less-than
severity	Violation severity level	high
branchPatterns	Target branches (empty = all)	[]
status	Rule status: enabled, disabled, warning	disabled
priority	Rule priority for ordering	high

Common Configurations

Require at least one approval:

conditions:
  - type: approvals
    operator: less-than
    value: 1

Require at least two approvals (recommended for production):

conditions:
  - type: approvals
    operator: less-than
    value: 2

Apply only to production branches:

branchPatterns:
  - main
  - master
  - release/*

Differentiating by Branch

You can create multiple rules with different thresholds:

# Strict rule for production
- name: PR to main without 2 approvals
  conditions:
    - type: approvals
      operator: less-than
      value: 2
  branchPatterns:
    - main
    - master
  severity: high

# Lenient rule for development
- name: PR to develop without approval
  conditions:
    - type: approvals
      operator: less-than
      value: 1
  branchPatterns:
    - develop
  severity: medium

Metadata Captured

Violations include:

• Actual approval count at merge time
• GitHub review decision (APPROVED, CHANGES_REQUESTED, etc.)
• PR number and target branch
• Merge timestamp

Related Checks

• PRs with Failing Checks - Another merge-time quality control
• PRs Without Issues - Ensures traceability