Add this checklist to the pull request that introduces a public CI template and do not merge until every line is answered. It covers the source, triggers, permissions, actions, secrets, runners and ownership, and takes about fifteen minutes for a typical workflow.
How to use it
Copy the list into the pull request description. The author fills it in, and the reviewer confirms. If any answer is no, either fix the file or write down why the risk is accepted. Keeping the answers in the pull request gives you a record when someone asks later why the pipeline looks the way it does.
The checklist
Source
- Where did it come from? Name the template and where you found it. If it came from GitHub's collection, say which one. If it came from elsewhere, link it.
- Is a newer version available? Compare with the current upstream file before you adopt an old copy.
Triggers and access
- Which events start it? Plain
pushandpull_requestare expected. Any use ofpull_request_target,workflow_run,issue_commentorissuesneeds a written reason. GitHub warns against combining the first two with a checkout of untrusted pull request code. - Is there a permissions block? It should set contents to read, with per job exceptions. GitHub recommends giving the token the minimum permissions required.
- Does it run on the right runner? Hosted by default. A self hosted label needs its own review.
Actions and code
- Is every action listed and pinned? Record owner, reference and whether you read the source. GitHub advises pinning to a full length commit SHA and auditing the source of any action.
- Is event data kept out of shell lines? Pull request titles, branch names and similar values should go through an environment variable, as GitHub documents for script injection.
- Does it download and run anything? Check each
curl,wgetand installer. GitHub notes hosted runners do not scan downloaded code for you.
Secrets
- Which secrets does it reference? Remove any the job does not need. Store the rest at the narrowest scope. For deploy or publish jobs, use an environment with required reviewers.
- Did you read the log after a test run? GitHub advises checking logs after valid and invalid inputs, since redaction is not guaranteed.
Ownership
- Does CODEOWNERS cover the workflows directory? So the next change to this file also gets a review.
- Who updates it? Name a person or team, and confirm Dependabot is enabled for action versions.
A compact version
| Area | Pass condition |
|---|---|
| Source | Named and current |
| Triggers | Ordinary, or reasoned |
| Token | Read by default |
| Actions | Pinned and read |
| Shell | No event data inline |
| Secrets | Minimal and scoped |
| Logs | Reviewed |
| Owner | Named, with CODEOWNERS |
Make it automatic where you can
Some of these checks can be done by tools. GitHub says CodeQL can scan GitHub Actions workflows for vulnerable patterns, and that OpenSSF Scorecards can flag risky workflows. A scanner will not replace the human questions about source and secrets, but it catches the mechanical ones.
For more detail on any item, see how to review a GitHub Actions workflow change.
Try it yourself
Click through it at your own pace, or open it full screen. Imagine each checklist line as a gate on this pull request, and decide which ones a tool could enforce.
Quick check
Who should review the checklist answers?
Someone other than the author, ideally a code owner who understands CI security.
Do I need the full list for a tiny change?
For a change that only bumps a pinned version, items 6 and 8 usually suffice. Adding a new template deserves the full list.
Sources
- Secure use reference, GitHub Docs
- Script injections, GitHub Docs
- Compromised runners, GitHub Docs
- Using workflow templates, GitHub Docs
Last reviewed: 19 October 2026.
