Establish code review and approval requirements
Implementation Effort: Low – Enabling branch protection rules that require peer approval, block self-approval, and dismiss stale reviews is a focused configuration change on protected branches. User Impact: Medium – Requiring peer review before merging changes how developers land code, so contributors must now get another person's approval on protected branches. Lifecycle Stage: Code
Overview
Require peer code review and approval before changes can merge into protected branches. Configure branch protection so authors cannot self-approve, stale approvals are dismissed after new commits, and sensitive paths require additional review where appropriate.
Code review is one of the most effective human-in-the-loop controls in the software development lifecycle. When a developer can push code directly to a protected branch without another person examining it, the organization has no verification that the change is intentional, correct, and free of malicious content. Threat actors who compromise a single developer account can inject backdoors, modify build logic, or exfiltrate secrets in a single commit if no approval gate exists. Even without malicious intent, unreviewed code is more likely to introduce vulnerabilities, misconfigurations, and logic errors that create exploitable weaknesses in production systems.
Require peer review with a minimum number of approvals on protected branches so every change is examined by someone other than the author. This directly enforces Verify explicitly. Both GitHub and Azure DevOps support branch protection or branch policy controls that require approvals, prevent authors from approving their own pull requests, and dismiss stale approvals when new commits are pushed. GitHub supports CODEOWNERS-based required reviews for sensitive paths, while Azure DevOps provides comparable enforcement through branch policies that automatically include reviewers by path filter.
This also supports Assume breach by limiting the damage a single compromised identity can cause. A threat actor who controls one account cannot merge code unilaterally—they must also compromise or deceive at least one reviewer. This separation of duties raises the cost and complexity of supply chain attacks targeting the source code layer.