GitHub Code Review Checklist: 7 Checks for Secure PRs

A pull request looks finished. Tests are green, the diff is small enough to skim, and two reviewers approve it in twenty minutes. Days later someone finds the change moved an auth middleware path the threat model had flagged months earlier. The description never mentioned authentication. Comments praised naming. The hole shipped because the review asked easy questions and left the blocking one to memory.

A GitHub code review checklist has to be ordered. Authors run checks before they open the pull request. Reviewers run checks on the diff. A policy gate runs the checks that must not depend on who is online. I would not pile a twenty-item memory list on top of that. Extra questions do not catch a middleware move if the threat model never enters the pull request. These seven checks follow that lifecycle: automated security context, author readiness, secure-diff questions, design judgment, risk-based reviewer choice, team process controls, and a full contribution path. Each one ends with a comment you can paste, plus a note on when enforcement belongs in code.

1. Automated Security Reviews

Pull requests combine human-written changes with AI-assisted code, so a uniform GitHub code review checklist cannot cover every risk. Automate repeatable security checks and reserve manual review for higher-risk decisions. GitHub's Copilot pull request assistant docs explain how teams can provide custom instructions for pull request reviews, including security guidance specific to a repository.

DevArmor's Automated Security Reviews brings design-level feedback into tools teams already use. It draws on tickets, design documents, repositories, and service metadata to maintain threat-model context as changes move through development. Policy-as-Code can flag a pull request, or optionally block it, when a change conflicts with an approved control. Traceable outcomes help teams explain why a merge was allowed.

The screenshot shows an automated review attached to the pull request, where authors and reviewers can act on it.

When the gate should block

Block only checks that can be verified from the diff or a linked artifact. Keep judgments that need context advisory, so reviewers can assess them rather than treating uncertain findings as automatic failures.

• Provenance: Record whether an agent contributed to the change and identify the human owner.
• Sensitive paths: Changes to authentication, data flows, cryptography, or dependencies should point to a relevant design decision.
• Tests: Generated tests need independent validation by a person or a separate check before they count as evidence.
• Limits: Enforcement depends on current artifacts and policies that reflect the team's design decisions.

Practical rule: If a pull request changes authentication, privileges, or sensitive data without a threat-model link, request changes. Green CI alone is not approval.

DevArmor-style enforcement adds value on sensitive paths, where a missed control can affect security or compliance. For low-risk documentation and copy changes, a ready-to-paste comment can prompt a useful check without making every change wait on a hard gate.

2. GitHub Docs, Helping Others Review Your Changes

Open the pull request only after you would approve it yourself. GitHub's guidance on helping others review your changes is the author half of a GitHub code review checklist: small scope, a title that states the behavior, a description a stranger can follow, and a self-review that includes builds and tests. It also calls out extra care for dependencies, authentication, permissions, workflows, and sensitive data. That is guidance, not a domain procedure, so you still have to write the security questions yourself.

GitHub's reviewing guide tells reviewers to ask what problem the pull request solves, why the change was needed, and how it relates to the linked issue. Most checklists skip that and jump to style. A clean diff can still implement the wrong behavior.

The author view in GitHub looks like this before anyone is tagged.

Paste this on your own pull request before you request review, and keep sharper comment patterns in a GitHub code review comments guide:

I self-reviewed the diff, CI is green, and the description states the problem, the out-of-scope behavior, and how to validate. Please check auth, permissions, and data handling if this touches them. Otherwise a normal functional review is enough.

Enforce the mechanical half in branch protection: required status checks, a linked issue, and a description template. Leave the “does this match the ticket” judgment to a person unless you have a policy that can read the acceptance criteria.

3. OWASP, Secure Code Review Cheat Sheet

A checklist is not automatically a better defect finder. In a controlled inspection study, ad hoc reviewers detected 42.8% of seeded defects while checklist reviewers detected 34.5%, and average effort was 55.62 minutes versus 49.08 minutes, with the inspection paper reporting no overall winner across effectiveness, effort, and false positives. I still want the OWASP Secure Code Review Cheat Sheet on high-risk pull requests. I do not want all of it on a CSS tweak.

OWASP covers preparation (architecture, threat models, critical assets, prior findings) and both whole-codebase and diff reviews. The questions hit input validation, authentication, authorization, cryptography, business logic, configuration, and monitoring, and they treat manual review as a complement to scanners. That breadth is the trade-off. Low-risk pull requests drown in it, and some questions need a security reviewer, not the nearest available approver. A tighter secure-review pass is outlined in this secure code review walkthrough.

For this diff, confirm authorization on every new branch, validation on external input, and no secret or weak crypto in the change. Link the threat-model item or say which one does not apply. Scanners do not close this comment.

Turn the repeatable slices into policy: dependency adds, auth annotations, and logging of sensitive fields. Keep business-logic questions as reviewer comments. A gate that blocks on “review security” with no evidence will get bypassed.

4. Google Engineering Practices, Code Review

Showing someone a list is not the same as telling them how to use it. A study titled “Do Explicit Review Strategies Improve Code Review Performance?” compared professionals with no guidance, a checklist, and a checklist-based strategy, measuring functional defects and cognitive load. The strategy paper does not publish final detection rates, so I will not invent them. The design is still the point: workflow has to say how to walk the change, not only which topics exist.

Google's engineering practices for code review do that without pretending to be a security form. Reviewers look at design, functionality, complexity, and whether the change fits the system and can be understood later. Authors get matching guidance. You will need to adapt reviewer count and turnaround to your release train. Google's bar is not a FinTech control catalog.

I can explain what this change does and why this design fits the service. Complexity looks justified. Please point at the function that would be hard for the next owner to change. If you cannot name one, approve the design and leave security gates to the required checks.

I would not encode “is this elegant?” as a merge block. Encode tests, owners, and policy hits. Leave suitability as a request-changes comment so reviewers do not hide design disagreements inside a failing bot.

5. GitLab Docs, Code Review Guidelines

Review depth should change with the diff, or large changes get a glance and small ones get a novel. A later study found explicit strategies most useful as complexity rose: a checklist beat a control on efficiency for one large change, while reviewers found fewer defects in demanding large changes than in small ones. That result is in the empirical review-strategy paper. GitLab's code review guidelines say the same thing in process language, even though you must translate merge-request terms onto GitHub.

Authors self-review, finish acceptance criteria, keep the description short, and include validation steps. Reviewer choice includes a domain expert when the area is specialized. Size and risk change who must look. The docs are light on security procedure, so pair them with a real control list rather than treating “pick an expert” as the whole check.

This pull request changes more than one service boundary. Please add the domain owner, split unrelated files, and list the validation steps in the description. I will review after that. A drive-by approval is not useful at this size.

Route ownership with CODEOWNERS for auth, billing, and infra paths. A bot can require the right reviewer. It cannot tell you the acceptance criteria were fantasy.

6. Microsoft Engineering Fundamentals Playbook, Engineering Fundamentals Checklist

Ask whether the team reviews at all before you argue about comment quality. CodePulse's 2025 Engineering Benchmarks looked at 802,979 merged pull requests from GitHub Archive and found that 90.3% of pull requests exceeding 1,000 lines shipped without formal review. A line-by-line checklist never runs on a change nobody was required to open.

The Microsoft engineering fundamentals checklist is the repository-level version of that question. It expects pull-request source control tied to work items, a defined review process, attention to reviewer count, automated checks, and turnaround, and a link from review to testing. It will not walk a single function. Reviewer-count rules also fail when one specialist is the only person who understands a ledger service. Use the checklist to see if policy exists, then tune the numbers to risk.

This repository has no required review on a change over the team size limit, and the work item is not linked. Please add the link and request the required reviewers before asking for more comments. I am not starting a line review until those gates exist.

That is the moment for DevArmor-style enforcement: required checks and merge blocking on high-confidence controls, with exceptions recorded. A wiki checklist that nobody is assigned will not change the next thousand-line pull request.

7. Python Developer's Guide, Pull-request Lifecycle

A company checklist that starts at “reviewer opens the diff” forgets half the work. The Python developer's guide to the pull-request lifecycle shows preparation, review, and how to leave a review on GitHub inside one contribution path. It is written for CPython, not for your payment service, and it is thinner on security than OWASP. The shape still transfers: the author prepares, CI speaks, a human reviews, and the merge waits on the project's rules.

Map your GitHub code review checklist onto those stages instead of one flat bullet list. Before open: scope, self-review, and a description that states intent. During the diff: design, security questions matched to risk, and a named owner. Before merge: required checks, code owners, and a block only where evidence is missing. If your team's path is still informal, start from a Git code review workflow and delete steps you cannot staff.

Lifecycle check: description states the problem and the rollback, CI is required and green, and a human owner has reviewed the sensitive paths. If any of those is missing, this stays in request changes. Please do not merge from a green badge alone.

Policy should own CI, owners, and control violations. People should own whether the change is the one the issue asked for. Mixing those up is how auth middleware slips through a friendly approval.

How the Reviewed GitHub Code Review Resources Compare

Turning Your Checklist Into Enforced Policy Before the Next Merge

Unresolved technical issues show up in merge outcomes, even if a checklist did not cause them. An MSR Challenge analysis of 78,955 pull requests from 88 projects found 33,910 merged and 45,045 not merged, and among 9,421 pull requests tied to recurring technical issues only 7.76% merged, according to the pull-request study. Read that as association. Still, a GitHub code review checklist that never records an open security concern is just a polite comment thread.

Start by enforcing three checks as policy-as-code. Require status checks so a weakened test run cannot sneak through, which is the same instinct as when you set up GitHub Actions testing. Require code owners on auth, data, and infrastructure paths. Require a linked threat-model or design decision when the diff touches those paths, and block only when that link is missing. Keep the paste-ready comments from this list in the repository so reviewers sound consistent without inventing new essays.

Revisit the list each quarter against incidents and escaped defects, not against how fast the median merge became. Drop questions nobody fails, and promote any comment you repeat every week into a check. Then pick one high-risk path in the codebase, write its review check today, and attach it to the next pull request that touches it.

DevArmor keeps threat models and approved design decisions tied to the pull request, then enforces those controls with Policy-as-Code so a GitHub code review checklist does not depend on who remembers the middleware. Security review shows up in GitHub, the IDE, and planning tools, with a trace you can hand an auditor. See how that gate works on your next sensitive change at DevArmor.