Review a stranger's pull request in this order: files that run code (workflows, build scripts, hooks), then dependency changes, then the actual feature. Approve workflow runs only after reading them, and remember the default skips approval for anyone with one previously merged commit.
Before you open the diff
Check how your repository treats fork workflows. GitHub's default requires approval for first-time contributors, and secrets are not passed to fork workflows in public repositories. Know your own setting; see fork pull request workflow settings.
Read these files first
- Workflow files. Any change under the workflow directory deserves a line by line read. A new trigger, a new step that downloads and runs something, or a changed permission block is a red flag.
- Build and install scripts. Makefiles, package scripts, setup files.
- Git hooks and tooling config. Anything that runs automatically on a developer's machine.
- Dependency manifests and lockfiles. New packages, changed sources, unfamiliar registries.
- Binary files. Ask why they are there.
Only after these, read the feature code itself.
Approve runs deliberately
Do not click approve on workflow runs before you have read what will run. Pull requests that change workflow files are the highest risk, because the workflow they trigger is the one you are about to approve. Be careful with workflows that use the pull_request_target trigger, since those run with base branch context whatever the approval setting says.
Check the contributor
Look at the account's history, but do not treat a long history as proof. GitHub's own caveat applies: one merged commit changes how the approval default treats them.
Use code owners
Require code owner review so changes to sensitive paths need the right team. The file must exist on the base branch. See CODEOWNERS for a monorepo.
Dependency check
Run a dependency scan on the pull request before merge, and read any new package name carefully for typos. See the pre-pull-request dependency check checklist.
Merge with confidence
Prefer a merge method that suits your signing policy; see merge methods and signatures.
Maintainers of small projects can lighten the load by setting the approval level to all external contributors and by keeping the workflow set small and simple. Fewer workflows means fewer places for a malicious change to hide, and a short workflow file is far easier to read in full. If a contribution is large, ask the contributor to split it, so each part gets a proper read, as covered in the post on small pull requests and security review.
Try it yourself
Click through it at your own pace, or open it full screen. Watch which findings block the merge.
Quick check
What do I read first in a stranger's pull request?
Files that execute code: workflows, build scripts and hooks, then dependency changes.
Is a long contribution history proof the account is safe?
No. Accounts can be compromised or built up on purpose, so review the diff regardless.
Safeguard policies and gates can run dependency checks on every pull request, so this review does not rely on memory.
Sources
Last reviewed: 19 October 2026.
