Add the workflows directory to a CODEOWNERS file and turn on required review from code owners in branch protection. Any pull request that edits a workflow file then needs approval from the named owners, which stops an outside contributor from quietly changing the pipeline that checks their code.
Why workflow files need their own rule
On the pull_request event, GitHub runs the workflow from the pull request's merge ref. A contributor can therefore propose a change to the workflow in the same pull request as the code. A harmless looking edit could drop a scan step, change a condition so a check is skipped, or point a job at a different runner.
GitHub's secure use guidance recommends exactly this protection: use CODEOWNERS to control how changes are made to workflow files, so proposed changes first require approval from a designated reviewer. Its approval guidance for fork runs also says to be especially alert to changes in the workflows directory.
Steps
- Create or edit CODEOWNERS in the repository.
- Add a line mapping the workflows directory to a small security or maintainer team.
- Add other pipeline files: build scripts called by workflows, Dockerfiles used in CI, dependency update configuration, and the CODEOWNERS file itself.
- In branch protection or rulesets, enable required review from code owners.
- Require at least one approval and dismiss stale approvals when new commits are pushed.
- Make sure the owners team has write access, since owners without it are not effective reviewers.
An example, written as plain lines in the file:
/.github/workflows/ @your-org/maintainers-security
/.github/CODEOWNERS @your-org/maintainers-security
/scripts/ci/ @your-org/maintainers-security
What to look for when you review
| Change | Why it matters |
|---|---|
| A new trigger such as pull_request_target | Moves the job into a privileged context |
| A permissions block widened | Gives steps more access |
| A new third party action | New code runs in your pipeline |
| A removed or conditional scan step | May let a check skip |
| A new runs-on value | May move a job to a different machine |
| New secrets referenced | Possible exfiltration path |
Limits to keep in mind
CODEOWNERS applies when changes arrive through a pull request. A maintainer with bypass rights can merge around it. Keep the owners list small, avoid giving admins routine bypass, and log exceptions.
Also remember that a first time contributor's workflows may need maintainer approval before running. Those two controls work together. Approval stops the run. CODEOWNERS stops the merge.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a gate collects its conditions before it lets a change through.
Where Safeguard fits
Safeguard's policies and gates add automated conditions to a pull request, while compliance and evidence automation can keep a record of reviews. The free scan is a starting point.
Quick check
Can CODEOWNERS stop a workflow from running?
No. It controls who must approve a merge. Fork run approval controls whether a first run starts.
Should the CODEOWNERS file be protected too?
Yes. List it in itself so owners cannot be changed without owner approval.
Sources
- Secure use reference, GitHub Docs
- Approving workflow runs from forks, GitHub Docs
- Events that trigger workflows, GitHub Docs
Last reviewed: 19 October 2026.
