Add .github/workflows to a CODEOWNERS file and turn on the branch protection option that requires code owner review. Then nobody can change your pipeline definitions without approval from a designated reviewer. GitHub's own hardening guide recommends this for workflow files.
Why workflow files deserve an owner
A workflow file decides what runs with your secrets and tokens. Anyone who can merge a change to it can change what your pipeline does. That includes adding a step that sends credentials elsewhere.
Normal code review catches a lot, but reviewers skim YAML. A named owner who knows what to look for is a better filter.
Where the file lives
GitHub's documentation says to create CODEOWNERS in .github/, the repository root or docs/. If more than one exists, GitHub uses the first it finds in that order. Each branch has its own file, and for review requests to work the file must be on the pull request's base branch.
Syntax in practice
# Pipeline definitions and release scripts
/.github/workflows/ @example-org/security-team
/.github/CODEOWNERS @example-org/security-team
/scripts/release/ @example-org/platform-team
Each line is a pattern followed by one or more owners.
Traps from the documentation
- Last match wins. If several patterns match a file, the last one takes precedence. Put broad rules first, specific ones later.
- Owners on one line. To assign several owners to one pattern, list them on the same line. If split across lines, only the last owner counts.
- Invalid lines are skipped. A syntax error means that line does nothing. Errors show in the UI and API, so look.
- Owners need write access. Individual owners need write access. Team owners must be visible and have write access.
- Some gitignore features do not work. Escaping
#,!negation and character ranges are not supported. - Paths are case sensitive.
- Size limit. The file must be under 3 MB or it is not loaded at all.
Also protect the file itself. GitHub advises assigning an owner to CODEOWNERS or the .github/ directory, otherwise someone can edit the rule that guards the rule.
Turning it on
The file alone does not block merges. In branch protection, enable the option that requires review from code owners, or use the equivalent in a ruleset. See branch protection versus rulesets.
Approval from any one owner on a line satisfies the requirement. Not all owners need to approve.
Pick the owners well
Use a team, not one person. Avoid making everyone an owner of everything. If every pull request needs the security team, they become a bottleneck and approvals turn into rubber stamps. Own the paths that carry real power: workflows, release scripts, infrastructure code and dependency manifests.
Safeguard policies and gates add an automated layer on top of human review. You can try the free scan at gold.safeguard.sh/scan.
Quick check
Does CODEOWNERS block merges by itself?
No. You also need to require code owner review in branch protection or a ruleset.
What if two owners are on separate lines?
Only the last one is used for that pattern. Put all owners on one line.
Sources
Last reviewed: 19 October 2026.
