Add a file named pull_request_template.md to the repository, and keep its security section to five or six honest questions. Long checklists get ticked without reading. A short one prompts the author to think about the risky parts of their own change before a reviewer has to.
Where the file goes
GitHub's documentation lists the locations: the repository root, a docs folder, or the hidden .github folder, always named pull_request_template.md. For several templates, use a PULL_REQUEST_TEMPLATE subfolder and pick one with the template query parameter.
Two practical points from the same page. With a single template, the contents appear in the pull request body automatically. And collaborators can use it only after it is merged into the default branch, so a template you are testing in a feature branch will not show up.
A template that gets used
## What and why
Short description. Link the issue.
## Risk
- [ ] Touches auth, permissions, or session handling
- [ ] Adds or changes a dependency
- [ ] Handles user input that reaches a query, shell or file path
- [ ] Changes CI, deploy or infrastructure files
- [ ] Logs or stores personal data or secrets
## How I tested it
Notice that the boxes are about what the change touches, not about confirming good behavior. Ticking one does not claim safety. It tells the reviewer where to look, and it may route the pull request to the right owner.
Why questions beat statements
"I have checked for injection" is a statement people tick by habit. "Handles user input that reaches a query" is a fact the author can answer in seconds, and a yes gives the reviewer a concrete line of inquiry.
Connect it to ownership
If a box is ticked for auth, make sure CODEOWNERS routes the pull request to the security team. See how to require code owner review. The template informs people. Ownership and branch rules enforce.
Keep it current
Review the template twice a year. If nobody has ever ticked a box, remove it. If incidents keep involving a category that is not listed, add it.
What not to put in
- Compliance language nobody understands.
- Anything you cannot check in a review.
- Promises such as "this is secure".
Short descriptions help too
The template should also push for a good description. Google's engineering guide says a description should say what changed and why, and treats it as a permanent record. See what security reviewers need in a pull request description.
A free scan of your dependencies is available at gold.safeguard.sh/scan.
Trying it for a month
Add the template, then read twenty pull requests a month later. Count how often each box was ticked, and how often the reviewer commented on the ticked areas. A box that is always ticked is too broad, and one that is never ticked may be irrelevant to your codebase.
Adjust the wording rather than adding more boxes. The goal is a template that takes the author under a minute and leaves the reviewer knowing where to start.
Quick check
Why does my template not appear?
GitHub says collaborators can use a template only after it is merged into the default branch, so check that and the file name and location.
Sources
Last reviewed: 19 October 2026.
