A good review covers design, behavior, complexity, tests, naming, comments, style and documentation. Security is not a separate pass in that list. You get more value by asking a security question at each stop. This post maps each concern in Google's published guide to one such question.
The list
The Google engineering practices page on what to look for names these: design, functionality, concurrency, complexity, tests, naming, comments, style, consistency, documentation, reviewing every line, context, and good things. The page itself has no dedicated security section, so the pairings below are suggestions, not quotes.
One question for each
Design. Does this belong here? Ask: does it put a trust boundary in the wrong place, such as validation in the client only?
Functionality. Does it do what the author intended? Ask: what happens with hostile input, missing authentication or another user's id?
Concurrency. The guide says parallel code needs careful checking for deadlocks and races, which are hard to catch by running it. Ask: can a race let two requests pass a check once?
Complexity. Complex code hides bugs. Ask: could a reader see every path that reaches the sensitive call?
Tests. The guide wants tests that fail when code breaks. Ask: is there a test for the denied case, not only the allowed one?
Naming and comments. Comments should explain why. Ask: if a check looks odd, is its reason written down so nobody deletes it?
Documentation. Ask: did the change alter a security relevant setup step that docs now misstate?
Every line
The guide says to review all human written code, and ask the author to clarify anything hard to understand. If you cannot follow a line, you cannot approve its safety. Say so.
Context
The guide asks reviewers to look beyond the diff to the whole file and system. A new endpoint looks fine alone, but the middleware that normally protects its siblings may not wrap it.
Specialists
For specialized areas, including security, the guide says to get a qualified reviewer. Use owners on sensitive paths so that happens by default.
Keep the good part
The guide also says to acknowledge good practices. Tell people when a test covers a nasty case. It makes careful behavior repeat.
A pocket version
- What can an attacker control in this change?
- What stops them?
- What test proves it?
A free scan of your dependencies is available at gold.safeguard.sh/scan.
Using it as a reviewer
You do not need to ask all of these questions on every pull request. Scan the change, decide which two or three concerns matter most, and spend your time there. A copy change needs almost none. A new endpoint needs most.
If you are new to reviewing, keep the list open in a second window for the first month. After that, the questions become habit and the list only matters for unfamiliar kinds of change.
Quick check
Does the Google guide have a security checklist?
No. The page says reviewers should get a qualified reviewer for security, but it has no dedicated security section. The pairings here are our own suggestions.
Sources
Last reviewed: 19 October 2026.
