Begin with the boundary that changed
A useful security review starts by identifying what the pull request changes about trust. Does a new endpoint accept input? Can a user select a different record? Does a background job act with stronger permissions than the person who started it? These questions keep the review tied to concrete behavior.
OWASP distinguishes review of a change from a baseline review of an entire application. A focused pull request can reveal a specific regression without establishing that the whole system is secure. Record the boundary you examined and the surrounding assumptions you still rely on. This makes the conclusion useful without overstating its coverage.
Follow input through its transformations
Choose one meaningful input and follow it from entry to use. For example, an uploaded filename may pass through validation, normalization, storage, and later download handling. The check that looks correct at entry may not describe the value used after a later transformation. Review the actual representation at each sensitive operation.
Distinguish safe-looking patterns from demonstrated safety. A database wrapper, template helper, or parser can be used correctly or incorrectly. Read the call and its arguments. Where a focused regression test is possible, use inputs that challenge the boundary you identified rather than collecting unrelated attack strings.
Review errors and retries as normal paths
Security-sensitive code must also behave sensibly when a request fails halfway through. Ask whether a failed operation leaves partial changes, exposes sensitive diagnostic data, or can be repeated to perform the action twice. Consider concurrent requests when the change depends on a limit, balance, reservation, or one-time action.
Do not remove a guard merely because it produces an error. A rejected stale request may be the intended response that prevents an incorrect write. Review whether the user can recover through a documented path, and verify that the attempted recovery does not bypass the original permission or consistency check.
Check the fix as carefully as the finding
A proposed remediation can introduce its own problem: a sample may repeat a real credential, a broader permission may hide an access error, or a fallback may return data outside the intended scope. Inspect the replacement behavior and verify the original trigger after the fix.
AntiCode's built-in checks examine a limited set of patterns in added lines, while managed AI review can propose evidence-linked findings for human assessment. Use those signals to focus this checklist. A clean run does not complete every item automatically, and a reported issue is not confirmed until its reasoning survives review. Finish with the specific evidence for the current revision and any unresolved questions that require another reviewer.
Further reading
Put it into practice
Start with a small change you are authorized to review. Follow the AntiCode setup guide, inspect each finding, and keep your tests and human approval in the loop.