A secure code review kata is a short, repeatable exercise: the team reviews one small, seeded change alone for ten minutes, compares findings for ten, and spends ten turning misses into checklist items. It trains the habit of reading code for abuse cases, not only for correctness.
Preparing the change
Write or adapt a change of 40 to 80 lines in your own stack. Seed it with two or three realistic flaws. Good candidates are a query built from user input, an endpoint that fetches an object by id with no ownership check, a secret read from a default value, or a missing check on a new route. Include one or two harmless oddities so that reviewers do not assume every odd line is a flaw.
Do not hide the flaws behind exotic tricks. Realistic and dull beats clever.
Running it
0 to 10: Solo review. Everyone reviews the diff on their own and writes comments as they would on a real pull request. No talking.
10 to 20: Compare. Go around the room. Each person states one finding. Group duplicates, and mark what nobody found.
20 to 30: Checklist. For each missed flaw, ask what prompt would have caught it. Write one line per answer. "Does any new route have an explicit access rule?" is a good example. Add the lines to your pull request template.
Rotating the kata
Run one every two weeks, with a new seeded change each time, or let a different team member prepare it. Preparing a kata teaches more than taking it, because the author must understand the flaw well enough to hide it. Reuse the pattern topics from your workshops, such as injection, output encoding and access control. See the review checklist by language for starting prompts.
Variations
- AI-generated change. Ask a coding assistant to produce the change, then review it. The point is to practice skepticism toward generated code.
- Dependency change. Review a diff that adds a package. Ask what you would check before merging, such as maintenance state, name similarity to a popular package, and install scripts. A free dependency scan from Safeguard can be run on the sample manifest as a final step.
- Pairs. For newer teams, review in pairs, and then compare across pairs.
What to avoid
Do not turn it into a contest or publicize who missed what. Do not reuse the same seeded flaw until everyone finds it, because the kata then becomes a memory test. Keep the tone curious, and have the group agree that missing a flaw is the expected starting point.
What good looks like after a few rounds
Reviewers start leaving comments about authorization and input handling on real pull requests. The checklist grows to a size that fits on one screen. New joiners learn the team's review standards by taking the kata in their first month.
Quick check
How many flaws should I seed?
Two or three, in a change small enough to read in ten minutes.
Last reviewed: 19 October 2026.
