Use layers: named owners review changes, branch rules prevent self-approval and bypass, release tags make versions immutable, and an environment gate controls the apply. No single setting covers a shared infrastructure repository, because the risk sits at several points between a commit and a live change.
Why one control is not enough
A shared infrastructure repository holds code that many teams run with their own credentials. A bad change can arrive through a module, a chart, a collection, a pipeline template or a plain pull request. The path from edit to effect has at least four steps, and each needs its own owner.
The layers
| Layer | Question it answers | Mechanism |
|---|---|---|
| Ownership | Who must look at this change? | CODEOWNERS with required code owner review |
| Review integrity | Was the approval independent and current? | Dismiss stale approvals, approve most recent push, no bypass |
| Release | Is the version callers use fixed? | Semantic version tags, protected tags |
| Consumption | Do callers move on purpose? | Pins, ranges only for owned modules, bot pull requests |
| Execution | Who allows the live change? | Environment reviewers, self-review block, branch limits |
Each layer maps to a guide on this blog:
- Ownership: CODEOWNERS for workflow and release files, and last match wins.
- Review integrity: most recent push approval and admin bypass.
- Release: versioning with semver and protecting tags.
- Consumption: pinning module sources.
- Execution: environment approvals.
Facts to build on
GitHub documents that owner review is mandatory when "Require review from Code Owners" is enabled, and that approval from any one listed owner satisfies it. It also says to add .github/workflows to the code owners file so workflow changes need a designated reviewer. For environments, only one required reviewer needs to approve, and up to six can be listed.
By default, admins and users with the bypass permission are exempt from branch protection unless "Do not allow bypassing the above settings" is selected.
Scale the rigour to the blast radius
Not every folder deserves five layers. A sensible split:
- High blast radius (network, identity, key management, shared CI templates): all layers, two reviewers by convention, no bypass.
- Medium (shared modules for workloads): owners, stale approval dismissal, tagged releases.
- Low (examples, docs): a single review.
CODEOWNERS can express this with different owners for different paths.
Decide what happens in an emergency
Rules that cannot bend get bypassed in a bad way. Write a break-glass path: who may use it, what gets logged, and who reviews it afterwards. See break-glass workflow design.
Check the model works
Once a quarter, open a test pull request that changes a protected path as a user without special rights. Confirm you cannot merge without owners, cannot approve your own push, and cannot deploy to production alone. If any step succeeds, fix the setting. Write down who last checked.
Where Safeguard fits
Safeguard's policies, gates and guardrails can enforce required checks on pull requests, and its compliance and evidence automation can collect the approval trail. It supplements your source host settings and does not replace them. You can run a free scan at gold.safeguard.sh/scan.
Quick check
Do I need all five layers everywhere?
No. Match the layers to blast radius, with the full set for network, identity, keys and shared pipeline templates.
Does one code owner approval satisfy the rule?
Per GitHub, approval from any one listed owner satisfies the requirement, so list owners with that in mind.
Sources
- GitHub: about code owners
- GitHub: about protected branches
- GitHub: managing environments for deployment
- GitHub: security hardening for GitHub Actions
Last reviewed: 19 October 2026.
