Give edit rights to a small platform or security group, require a reviewed pull request for every change, and add code owners on the templates directory. The template repository shapes every new workflow in the organization, so its access list deserves the same care as a production deploy repository.
Why this repository matters
When your organization publishes templates, each one is a workflow file inside a .github repository, in a workflow-templates directory. Teams pick a template, GitHub copies it into their repository, and from then on it runs with that repository's token and secrets.
So a change to a template does not affect running pipelines directly. It changes what the next dozen repositories start with. A subtle edit, such as a widened permissions block or an extra download step, can spread without anyone noticing until teams adopt it.
A realistic access model
| Role | Access to template repo | Why |
|---|---|---|
| Platform or security owners | Write, via pull request | They maintain the defaults |
| Team leads | Read, can open pull requests from forks or branches | They can propose changes |
| All developers | Read | They need to see what they copy |
| Automation accounts | None, unless a documented need exists | Fewer paths to abuse |
Keep the write group small enough that you can name every member.
Controls to switch on
- Branch protection. Require pull requests for the default branch, and require at least one approving review.
- Code owners. GitHub documents CODEOWNERS as a way to require approval from a designated reviewer for changes to files such as those under the workflows directory. Apply it to
workflow-templatestoo. - Dependabot for actions. If your templates call actions, GitHub notes Dependabot can keep those references current through reviewed pull requests.
- Scanning. GitHub says CodeQL can scan workflow files and Scorecards can flag risky patterns. Run them on the template repository itself.
- A review checklist. Write down what reviewers must check: permissions, triggers, pinned actions, secrets, downloads.
What reviewers should look for
- A top level permissions block present, with read access to contents.
- No
pull_request_targetorworkflow_rununless there is a documented reason. - No expressions that place event data directly inside shell lines.
- Every action pinned and from an approved owner.
- No hard coded credentials or hosts.
For the broader review pattern, see how to review a GitHub Actions workflow change.
Audit and communication
Use pull request titles that say what changed and why. When a template changes in a way that existing repositories should copy, write a short note and send it to the teams. Since templates do not update repositories already created, communication is your update mechanism.
Quick check
Should security approve every template change?
For changes to permissions, triggers, secrets or downloads, yes. Pure wording changes can go through a lighter review.
Can a developer bypass a template by writing their own workflow?
Yes. Templates guide new workflows but do not enforce anything. If you need enforcement, use organization level Actions policies, not templates alone.
Sources
Last reviewed: 19 October 2026.
