A developer can start doing useful security reviews after a week if you teach a method rather than a list of bugs: day one for the method, day two for checklists, day three for shadowing, day four for a supervised review, and day five for feedback and a first solo change. Keep scope small and the feedback specific.
What the week is for
The goal is not expertise. It is a reviewer who knows what to look for, can say what they did not check, and knows when to ask. The OWASP Secure Code Review Cheat Sheet lists good practices for review teams that make a good syllabus: use standardised checklists and templates, maintain a knowledge base of common issues, track metrics on review effectiveness, and provide regular security training.
Day 1: the method
Teach one way of reading a change. The cheat sheet's diff-based steps are a good frame: analyse the impact on existing security controls, identify new attack vectors, verify security at modified trust boundaries, check new integrations, and ensure no security regression.
Give them two ideas to carry:
- Trace data from where it enters to where it lands.
- Look for what is missing, such as a check, a test or a limit, as well as for what is wrong.
Have them read two old, closed pull requests and write down what they would have asked.
Day 2: checklists for your stack
Hand over your team's short checklist, not a long generic one. OWASP's review checklists cover input validation, authentication and sessions, authorization, cryptography, business logic, and configuration and deployment. Choose the five items that matter most in your codebase, for example: queries are parameterised, routes check the object, secrets come from the vault, errors are generic, new packages are justified.
Add the codebase specifics that a new reviewer cannot guess: which helper does authorization, where input validation lives, which files are sensitive.
Day 3: shadow
Have the new reviewer sit in on, or read along with, two real reviews by an experienced person. Ask them to review silently first, then compare. The gaps are the lesson. Google's guidance on comments suggests explaining reasoning and labelling severity, so ask the experienced reviewer to narrate both.
Day 4: supervised review
Give them a real, low-risk pull request. They review it, and a mentor reviews their review. Look at four things:
- Did they find the real issue, if there was one?
- Were the comments specific, with a location and reason?
- Were the labels right, blocking versus optional?
- Did they say what they did not review?
Day 5: feedback and first solo review
Hold a thirty minute debrief. Praise what was done well, with reasons, because Google's guidance recommends commenting on good work and explaining why. Name two things to improve. Then assign a tier 1 change to review alone, with the mentor available.
Exercises that help
| Exercise | What it teaches |
|---|---|
| Spot the missing check in a small snippet | Looking for absence |
| Write a review comment for a vulnerable snippet | Specific, kind, actionable wording |
| Read just a diff's deleted lines | Regression awareness |
| Classify five comments as nit, optional or blocking | Severity judgment |
What to avoid
- Dumping a hundred page guide on day one.
- Teaching vulnerability names alone without a reading method.
- Letting a new reviewer approve high risk changes alone. Tier by risk, and start them on routine work.
After the week
Add them to the review rota, track whether their findings are valid, and check in after a month. OWASP's list of metrics includes the ratio of valid findings to total findings, which tells you how well the training landed.
Quick check
Do new reviewers need a security background?
No. A developer who knows the codebase and has a method often finds more than an outsider with general security knowledge.
How do we keep the knowledge base fresh?
Add an entry whenever a review finds something new, and prune entries that no longer apply. Review it each quarter.
Sources
- OWASP Secure Code Review Cheat Sheet
- Google Engineering Practices: How to write code review comments
Last reviewed: 19 October 2026.
