Add a CODEOWNERS file that names a small group as owner of the .github/workflows directory and of the CODEOWNERS file itself, then enable "Require review from Code Owners" in your branch protection or ruleset. Any change to pipeline definitions then needs approval from someone who understands them.
The risk this addresses
Workflow files decide what runs with your secrets. A one line change can add a step that sends credentials out, or loosen the token permissions. If any teammate can merge a workflow change with a casual approval, your pipeline is only as safe as your least careful reviewer.
GitHub's secure use reference suggests exactly this control: put your workflow directory on the code owners list so that proposed changes first require approval from a designated reviewer.
Step by step
- Choose the owners. A team of two or three people who understand pipelines works better than one person who becomes a bottleneck. GitHub notes that approval from any one listed owner satisfies the requirement, so a team handle is practical.
- Create the file in
.github/, the repository root ordocs/. GitHub looks in that order and uses the first one it finds. Using.github/is the option GitHub recommends for protecting the file itself. - Add the rules:
/.github/workflows/ @your-org/pipeline-owners
/.github/CODEOWNERS @your-org/pipeline-owners
/.github/dependabot.yml @your-org/pipeline-owners
- In branch protection or a ruleset for the main branch, require pull request reviews and enable review from code owners.
- Test it. Open a pull request that touches a workflow file and confirm the owners are requested and the merge is blocked until they approve.
Things that catch teams out
- The file must be on the base branch. GitHub's docs say that for owners to receive review requests, CODEOWNERS must exist on the base branch of the pull request, and pull requests use the version from the base branch. A change to CODEOWNERS in a pull request does not apply to itself.
- Owning the CODEOWNERS file. The docs say that to protect a repository fully, you also need an owner for the CODEOWNERS file, otherwise someone can edit the rules.
- Branches differ. Each CODEOWNERS file assigns owners for one branch, so check the rules on release branches too.
- Other places that run code. Add composite actions, reusable workflows and scripts called by workflows to the list. A workflow that calls
./scripts/deploy.shis only as safe as that script. - Admin bypass. If administrators can bypass the rule, owner review is optional for them.
Review habit for owners
Owners should read each workflow change with a short checklist:
- Did permissions widen?
- Is a new action added, and is it pinned to a SHA?
- Did a trigger change, especially to pull_request_target or workflow_run?
- Are secrets now used in a job that did not use them before?
- Does anything now download and run a script?
Where Safeguard fits
Code owner review catches intent. Safeguard's gates and dependency scanning add automated checks on what the change pulls in, so owners spend time on the pipeline logic. Try the gate yourself below.
Click through it at your own pace, or open it full screen.
Quick check
Do rulesets support code owner review?
GitHub's docs describe rulesets as an alternative to branch protection rules, and the code owners page points to them for the same purpose. Check the current rule list for your plan.
Who should own workflow files in a very small team?
Two people, so one can be away. If you only have one, require review from a second person you trust for those paths.
Sources
- About code owners, GitHub Docs
- Secure use reference, GitHub Docs
- About protected branches, GitHub Docs
Last reviewed: 19 October 2026.