reviewing-code-changes

Reviewing Code Changes

Reviewing a diff is not auditing a codebase in miniature. The diff shows you what changed but hides what the change means — the caller that now receives untrusted data, the check that used to run, the assumption that no longer holds. Reviewing only the added lines is the standard way to miss the bug.

When to Use

• Security review of a pull request, branch, or commit range
• Pre-commit or pre-merge check on your own changes
• Assessing risk of a dependency bump or config change
• Reviewing an AI-generated change before it ships

When NOT to Use

• Whole-codebase audit — use auditing-code-for-vulnerabilities
• Runtime testing of the deployed change — use the relevant testing skill
• Dependency/CI changes as the main subject — use auditing-supply-chain

Get the Real Diff First

# Against the actual merge base, not against whatever HEAD happens to be
BASE=$(git merge-base HEAD origin/main)
git diff --stat $BASE...HEAD
git diff $BASE...HEAD

# Rename and whitespace noise hides real changes
git diff -M -C -w $BASE...HEAD

# Files changed most, and by whom — where to spend attention
git diff --numstat $BASE...HEAD | sort -rn | head -20

Three things to establish before reading code:

1. What is this change trying to do? Read the PR description and the tests. A security review without the intent is pattern matching.
2. Does the diff match the description? Unexplained files — a config change, a new dependency, a workflow edit riding along with a feature — are the highest-signal thing in a review.
3. What is the change's exposure? A change to an unauthenticated request path deserves an order of magnitude more attention than an internal refactor.

Triage: Where to Spend the Review

Not all diffs deserve equal time. Rank hunks by what they touch:

Priority	Signals
Critical	Auth/authz logic, session handling, crypto, input parsing on an untrusted boundary, SQL/command/template construction, file path handling, deserialization, CI/CD workflows, IAM/security-group config, dependency additions
High	New endpoints or routes, new tool/RPC surface, error handling on security paths, logging of user data, tenant scoping, cache keys, rate limits
Medium	Business logic that consumes validated input, refactors that move security-relevant code
Low	Tests, docs, formatting, comments — but read test deletions