Direct Commits to Protected Branches

This compliance check detects commits pushed directly to protected branches (like main or master) without going through a pull request. Direct commits bypass code review and other quality gates, creating compliance and quality risks.

What It Detects

Dike identifies commits that:

1. Were pushed to a protected branch pattern (e.g., main, master, release/*)
2. Have no associated pull request

Scenarios that trigger violations:

• Developer pushes directly to main with git push origin main
• Force push to main branch
• Commits made via GitHub web editor on main
• Automated scripts pushing directly to protected branches

Examples that don't trigger violations:

• Commits that were part of a merged PR
• Merge commits created by GitHub when merging PRs
• Commits to feature branches

Why It Matters for SOC2

Direct commits to production branches represent one of the most significant control failures:

• CC6.1 - Change Management Bypass: Direct commits bypass the entire change management process—no PR, no review, no approval, no CI checks.
• CC6.6 - Separation of Duties Violation: A single individual can make unreviewed changes to production code.
• CC7.1 - System Integrity Risk: Unreviewed code may contain bugs, security vulnerabilities, or malicious changes.
• CC8.1 - Audit Trail Gap: Without a PR, there's no record of what changed or why.

This is often the first check auditors ask about because it's such a fundamental control. A single direct commit to main can raise serious questions about your entire change management process.

How to Resolve Violations

Immediate Resolution

1. Review the commit: Examine what was changed and assess risk:

   git show <commit-sha>

2. Create retroactive documentation: Open a Jira issue and link it to the commit, documenting:

   • What was changed
   • Why it was pushed directly
   • Who authorized it
   • Any testing performed

3. Acknowledge with justification: If it was an authorized emergency:

   • Reference the incident ticket
   • Document the business justification
   • Note any compensating controls applied

4. Consider reverting: If the change is risky and wasn't properly reviewed, revert and re-apply through proper channels.

Preventive Measures

• Enable branch protection: This is the most important control:

  Settings → Branches → Branch protection rules
  ✓ Require a pull request before merging
  ✓ Require approvals
  ✓ Do not allow bypassing the above settings

• Disable force push: Prevent history rewriting on protected branches.

• Require linear history: Prevents merge commits that could include unreviewed code.

• Configure for admins too: Ensure administrators cannot bypass protections:

  ✓ Do not allow bypassing the above settings

• Audit access regularly: Review who has push access to protected branches.

Configuration Options

Rule Configuration

name: Commits to main without PR
trigger: commit_pushed
status: enabled
priority: high
conditions:
  - type: without-pr
    operator: equals
    value: true
actions:
  - type: create-violation
    severity: high
branchPatterns:
  - main
  - master

Configurable Parameters

Parameter	Description	Default
branchPatterns	Branches to protect	['main', 'master']
severity	Violation severity level	high
status	Rule status: enabled, disabled, warning	disabled
priority	Rule priority for ordering	high

Branch Pattern Examples

Standard production branches:

branchPatterns:
  - main
  - master

Including release branches:

branchPatterns:
  - main
  - master
  - release/*
  - hotfix/*

Environment-specific branches:

branchPatterns:
  - main
  - production
  - staging

Combining with Other Conditions

You can require both PR association AND issue reference:

name: Untracked commits to main
conditions:
  - type: without-pr
    operator: equals
    value: true
  - type: missing-issue-key-pattern
    operator: matches
    value: "[A-Z]+-[0-9]+"
branchPatterns:
  - main

This catches commits that both bypass PR review AND lack issue tracking.

Metadata Captured

Violations include:

• Commit SHA and message
• Whether the commit has associated PRs
• Branch name
• Author information
• Push timestamp

Emergency Procedures

If your team needs to occasionally push directly (hotfixes, emergencies), establish a documented procedure:

1. Pre-authorization: Define who can authorize emergency pushes
2. Documentation: Require immediate incident ticket creation
3. Post-review: Mandate review within 24 hours
4. Acknowledgment: Use Dike's acknowledge feature with incident reference

This creates an audit trail showing that even emergency changes followed a controlled (if expedited) process.

Related Checks

• PRs Without Approvals - Catches PRs merged without review
• Commits Without Issues - Ensures commit traceability
• PRs with Failing Checks - Catches CI/CD bypass