Where more than one person can merge, the default branch requires an approving review
A review catches what no scanner reads: the change an insider lands on purpose, and the change a stolen account lands in someone else’s name. Nobody can approve their own change request, so a repository where one principal holds every merge path cannot satisfy this rule and gains nothing from being asked. Requiring an approval there produces one of two outcomes, a maintainer who cannot merge, or a bypass entry that exempts the only person the rule could bind. Both cost the repository a control it did have. Where two or more people can merge, the approval is the one control that puts a second pair of eyes on the diff before it lands. Skipping this rule has a scored consequence worth stating. OpenSSF Scorecard tiers the Branch-Protection check and gates each tier on the one below it, with force push and deletion in tier 1, review in tier 2, and status checks in tier 3. A repository that blocks force pushes and requires CI but not review therefore scores 3 out of 10 rather than 8. Meet the standard here, not the score.
Observable check
where two or more principals hold push, maintain, or admin access, the default branch requires at least one approving review, and where a CODEOWNERS file exists its review is enforced. Read the access list rather than inferring it, with gh api repos/{owner}/{repo}/collaborators?affiliation=all plus the repository's teams on GitHub, or project members at Developer or above on GitLab. A repository where one principal holds every merge path falls outside this rule rather than failing it. Where the access list cannot be read, which answers 403 Must have push access to view repository collaborators for a caller without push access, the rule is unknown rather than pass or fail.
Where this comes from
Last read against these sources on 2026-07-30.
Scorecard Branch-Protection is where the scope condition comes from, in its own voice: 'Although requiring code review can greatly reduce the chance that unintentional or malicious code enters the "main" branch, it is not feasible for all projects, such as those that don't have many active participants.' The same check tiers what R-SEC-04 used to bundle, and gates each tier on the one below it: 'a tier must be fully satisfied before you can earn points from the next tier.' Tier 1 is force push and deletion at 3 of 10, tier 2 is one reviewer at 6, tier 3 is one status check at 8. That gating is what puts the 3 of 10 figure in the rule. Reading the access list to decide whether the rule applies is this project's own position; Scorecard names no participant count and offers no threshold, so the standard picked the smallest one that makes review mean anything, which is a second principal who can merge.