Start with a short CODEOWNERS file covering authentication code, CI workflows, infrastructure definitions and the CODEOWNERS file itself, then enable required code owner review on the main branch. A short list that is enforced beats a long list that nobody reads.
Pick paths by blast radius
Ask what a bad change in this folder could do without anyone noticing. Good first candidates:
- Authentication and authorization code.
- CI and deployment definitions, such as the workflow folder.
- Infrastructure as code and cluster manifests.
- Dependency manifests and lockfiles.
- The CODEOWNERS file.
Leave most application code with a default team. Over assigning means owners drown in requests and start approving without reading.
A starter file
* @org/engineering
/auth/ @org/security
/.github/workflows/ @org/platform
/infra/ @org/platform
/.github/CODEOWNERS @org/security
Turn it into a rule
The file only requests reviews. GitHub's documentation says to enable "Require review from Code Owners" in a branch protection rule, and notes that rulesets are an alternative. After that, pull requests touching owned code need an owner's approval before merging. One listed owner approving is enough.
Protect the file itself
The documentation suggests assigning an owner to the CODEOWNERS file or the .github/ directory. Without that, anyone with write access can remove the rule in the same pull request that breaks it.
Pair it with dismiss stale approvals
An owner approves, then the author pushes more changes. Without the dismiss setting, the approval could stand for code the owner never saw. The branch protection documentation says approvals are invalidated when the diff changes after approval. See what dismiss stale approvals protects.
Keep owners reachable
Use teams, not individuals, so a holiday does not block merges. Teams must be visible and have write access. Check that each team has at least two people.
Admin bypass
By default, admins and users with the bypass permission are exempt from branch protection. The documentation describes a setting that applies the rules to them too. Decide deliberately and write the decision down.
Measure it
After a month, look at how long owner reviews take and how often owners approve with no comment. Slow reviews mean too many paths, and silent approvals mean owners lack context.
A free scan of your dependencies is available at gold.safeguard.sh/scan.
Rolling it out without drama
Start in the open. Tell the owning teams which folders you plan to assign and why, and agree on a review turnaround before you switch enforcement on. A reasonable first target is one business day for a first response.
Turn on required review for one repository first, usually the one with the most sensitive code. Watch for pull requests that sit waiting. If owners are the bottleneck, add people to the team or narrow the patterns before copying the setup to other repositories.
Quick check
Do I need every owner to approve?
No. On GitHub, approval from any one listed owner for a pattern satisfies the requirement. Use separate patterns or additional rules if two groups must both approve.
Sources
Last reviewed: 19 October 2026.
