Before asking for review, check that the change is one self-contained piece, that the description says what it does and why, that tests are included, and that you have named any new input, permission, dependency or external call. Ten minutes of this saves the reviewer an hour.
Why the author goes first
A reviewer sees the change cold. Google's public guidance on small changes notes that although you know your code intimately, the reviewer often has no context, so a size that seems fine to you can overwhelm them. Self-review is how you close that gap.
It also changes who finds the problem. Catching your own missing authorization check before anyone else sees it costs nothing and builds trust.
The checklist
Work through it on the diff in your review tool, not in your editor. The different view makes you read it more like a stranger.
Scope
- Is this one self-contained change? Google's guidance suggests one thing per change, with its tests, and says 100 lines is usually reasonable while 1,000 is usually too large, though it leaves the final call to the reviewer.
- Are unrelated edits, such as formatting sweeps or renames, in a separate change?
Description
- Does it say what changed and why, in a sentence a newcomer could follow?
- Does it list anything security relevant: new endpoint, new permission, new file path handling, new outbound call?
Trust boundaries
- Where does outside data enter, and where does it end up? Follow it through to the database, the filesystem, the shell or the page.
- Is every new route protected, and is the check made on the object, not just the user?
- Did you remove or loosen any check? Say so in the description.
Dependencies and config
- Did you add or bump a package? Note why, and check the lockfile diff matches what you expect.
- Did you touch configuration, environment handling or CI files?
Tests
- Is there a test for the unhappy path, such as a user asking for someone else's record?
- Does the change include related test code, as Google's guidance recommends?
Write the risk note
Add a short section to the description:
Security notes
- New endpoint: GET /exports/{id}, scoped to current user's account
- No new dependencies
- Removed the legacy admin override in export.py (see line 88)
This is not paperwork. It is a map. The OWASP Secure Code Review Cheat Sheet tells reviewers of diffs to identify modified files and affected components, understand the purpose of the change and prioritise high-risk modifications. Your note does the first three for them.
What not to do
Do not ask for review while checks are red. Do not push a large change and hope the reviewer asks to split it. Google's guidance says reviewers may reject a change for size alone, and splitting afterwards is much harder than starting small.
Try it yourself
Open the demo to see how a pull request gate presents results to an author. Notice which findings you could have caught in your own self-review.
Click through it at your own pace, or open it full screen.
Safeguard's policies and gates run on pull requests, so some of this checking, such as dependency changes, can happen before a human reviewer is asked.
Quick check
How long should self-review take?
For a normal sized change, about ten minutes. If it takes much longer, the change is probably too big and should be split.
Do I need a risk note on every pull request?
Not on typographical fixes. Add one whenever the change touches input, permissions, files, dependencies or configuration.
Sources
Last reviewed: 19 October 2026.
