Review a contractor's pull request in two passes: first look at which files changed, because some file types change trust more than others, then read the logic. Pay special attention to dependency files, workflow and build scripts, permission settings, and anything that sends data outside the system.
Pass one: look at the file list before the code
Open the Files changed tab and sort the files into risk groups before reading a line.
| Group | Examples | Why it matters |
|---|---|---|
| Dependency files | Manifests, lock files | New third party code enters the build |
| Pipeline and build | Workflow files, Dockerfiles, build scripts | Changes what runs with credentials |
| Access and config | Permission settings, environment files, infrastructure definitions | Changes who can do what |
| Ownership files | CODEOWNERS, branch rule configuration | Can weaken the review itself |
| Application code | Everything else | The usual review |
Anything in the first four groups deserves a named owner. GitHub's Actions guidance suggests using CODEOWNERS to control how changes are made to workflow files, so that edits to the workflow directory first require approval from a designated reviewer.
Pass two: six questions
- New packages. Is each added dependency needed, from a recognizable publisher, and approved? GitHub's dependency review view lists changes to indirect dependencies and flags known vulnerable versions. See requiring approval for new dependencies.
- Build and pipeline edits. Does any change add a step that downloads and runs something, alters permissions of the workflow token, or references a secret? GitHub recommends pinning actions to a full-length commit SHA and granting the GITHUB_TOKEN the minimum permissions, so flag a new action reference that is not pinned.
- Data leaving the system. Search the diff for new outbound network calls, logging of request bodies, or analytics code that was not in the ticket.
- Hard coded values. Look for tokens, keys, internal hostnames or test credentials committed in the change. If you find one, treat it as exposed and rotate it.
- Scope. Does the change match the task? Large unrelated edits, renamed files or reformatting of a sensitive file make a quiet change harder to spot.
- Tests and behavior. Do tests prove the change, and were any existing tests deleted or loosened?
Approval hygiene
- Require a reviewer who is not the author. GitHub also offers a setting that requires approval of the most recent push by someone other than the person who pushed it.
- Dismiss stale approvals. GitHub records the diff at the time of approval and dismisses the review if new changes alter it, which blocks the pattern of getting approval and then adding more code. GitHub notes that dismissing stale reviews is the safer option if you are worried about pull requests being hijacked.
- Read the commit list, not only the final diff, when something looks off.
When to ask for more
Ask the contractor to explain any change you cannot map to the ticket. A good contractor answers quickly. An evasive answer is information. Do not merge what you do not understand, and do not feel rushed by a delivery date.
Make the pass repeatable
Put the six questions in the pull request template so contractors answer them up front, and keep the group table in your review guide. For accountability, pair the process with the ownership map and the offboarding checklist.
Safeguard's policies and gates can automate the mechanical parts of this pass on every pull request, including dependency and vulnerability checks, and its reachability analysis helps separate advisories that matter from ones that do not. See the free scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through it to see how reachability analysis separates vulnerable packages that your code calls from ones it never touches.
Quick check
Which files deserve extra review?
Dependency manifests, lock files, workflow and build files, access configuration, and ownership or branch rule files.
Why dismiss stale approvals?
So new commits added after approval cannot merge without a fresh review of the changed diff.
Sources
Last reviewed: 19 October 2026.
