A pull request template should ask four to six short security questions: what data changes, what input is new, who can reach it, what dependencies were added and how it was tested. Short, specific prompts get real answers. A long checklist gets ticked without reading.
Why a template helps
Code review is where a second person looks at the change. NIST's Secure Software Development Framework asks organizations to decide when code review and analysis are used, and to record and triage the issues found in the team's workflow. A template helps the author hand the reviewer the facts they need, so the review can focus on risk.
It also builds a habit. An author who must write "no new input" has to check that it is true.
A template you can copy
Paste this into your repository's pull request template file and adjust the wording.
## Security notes
- Data: what data does this change read, write or expose? (or "none")
- Input: what new input does it accept, and where is it validated?
- Access: who can reach this, and how is that enforced?
- Dependencies: any new or updated packages? (name and reason)
- Testing: how did you test the failure case, not just the success case?
Five lines is a good target. Add more only when a repeated incident shows a gap.
What each question catches
| Question | What it surfaces |
|---|---|
| Data | Accidental logging of personal data, new sensitive fields |
| Input | Missing validation, new injection paths |
| Access | Endpoints that skip an authorization check |
| Dependencies | Unvetted packages, abandoned libraries |
| Testing | Features tested only on the happy path |
Make it work in practice
- Keep it short. Five questions, one line each.
- Allow "none" with a reason. "None, UI text only" is a fine answer.
- Have reviewers read it first. If the notes are empty, ask for them before reviewing the code.
- Pair it with automation. Use scanners and checks in the pipeline for what machines do better, and use the template for what they cannot know.
- Review the template quarterly. Remove a question nobody answers meaningfully, and add one that matches a recent miss.
What not to put in it
- Generic reminders like "write secure code".
- A list of every OWASP category. The OWASP Proactive Controls and ASVS are good references, but a template is not the place to reproduce them.
- Questions only a security expert can answer. If the author cannot answer, the question belongs in design review.
Template vs tooling
A template does not replace automated checks. Dependency scans, static analysis and secret detection should run on every pull request and block when criteria fail. The template covers context the tools cannot see, such as intent, data sensitivity and the reason a dependency was added.
Special cases
For pull requests opened by bots, such as dependency updates, a short note about what changed and the risk of the update serves the same purpose. For infrastructure changes, replace the data and input questions with "what permissions or exposure change?" and "what is the rollback?"
Safeguard can scan dependencies and apply policy gates on pull requests, so the dependency question has data behind it. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. See how automated checks and a human review fit together on one pull request.
Quick check
How many security questions should a template have?
Four to six. Each one should be answerable in a line and should change what the reviewer looks at.
Does a template replace automated scanning?
No. Scanners find known classes of issue. The template captures intent and context that tools cannot see.
Sources
Last reviewed: 19 October 2026.
