Use Case: Code Security
Branch protection bypass
A senior engineer force-pushed to the main branch at 11:47 PM, bypassing the two-required-reviewers rule. The commit included a configuration change to the production authentication service. ManySignal flagged the bypass immediately.
The emergency merge that wasn't an emergency
Branch protection rules exist to enforce code review before changes reach production. But branch protection is only as strong as the controls around admin access. Repository admins and organization owners can bypass branch protection by design — and attackers who compromise these accounts, or insiders who abuse the access, can push arbitrary changes directly to protected branches without the review that would catch malicious content.
The detection requires correlating the bypass event with its context: was there an incident ticket? Was this actor on the authorized bypass list? Was the push during business hours? What did the commit actually change? All of these questions have answers in the available audit data, but require automated correlation to answer at the speed a bypass occurs.
rule: branch_protection_bypass
type: github_event + authorization_check
sources:
- github_audit_log
- github_webhook_push_events
- github_branch_protection_api
trigger:
- event: push.forced == true AND branch IN protected_branches
- OR:
- event: branch_protection_review_required_bypass
- condition: actor NOT IN [authorized_bypass_actors, codeowners]
enrichments:
- commit_diff: risk_analysis (auth changes, infra configs, secrets)
- itsm_correlation: incident_ticket, change_window
- actor_location: ip_geolocation, business_hours_check
- deployment_trigger: ci_pipeline_triggered_post_push
mitre: T1195.002 (Supply Chain Compromise), T1554 (Compromise Client Software Binary)MITRE ATT&CK mapping
Branch protection bypass FAQ
What branch protection bypass methods does ManySignal detect?
Admin-privilege force push to protected branches, temporary disablement of required reviewers, bypassing required status checks (marking CI as required then disabling the check), pushing via deploy keys that have admin access, and using the GitHub API to bypass protections that the web UI enforces.
Who is authorized to bypass branch protection, and how does ManySignal know?
ManySignal integrates with GitHub's CODEOWNERS file and the list of bypass actors configured in branch protection rules. Only listed individuals can legitimately bypass reviews. Any bypass by an actor not in these lists triggers an alert. Bypass by listed actors is logged for audit purposes but at lower severity.
Does ManySignal detect branch protection settings being changed to be less restrictive?
Yes. Changes to branch protection rules themselves — removing required reviewers, reducing required approvals from 2 to 1, disabling required status checks — trigger a detection. These configuration changes are often a precursor to a subsequent bypass.
Can this detect bypass attempts by repository admins who legitimately have bypass rights?
Admin bypasses are expected in some workflows (hotfixes, emergency deployments). ManySignal differentiates by correlating with the change management context: an admin bypass linked to a P1 incident ticket during business hours is expected. An admin bypass at 3 AM from an unusual IP without a linked ticket is flagged.
Know every time branch protection is bypassed and why
Real-time push event monitoring with commit diff analysis and change management correlation.