To do a secure code review, find where untrusted data enters the change, follow it to where it is used, check authentication and authorization on every new path, look for secrets and risky dependencies, and make sure branch protection forces a second reviewer. Use a short checklist so each review asks the same questions.
Key takeaways
- Review the data flow, not just the diff lines.
- Every new endpoint needs an authorization check, not only authentication.
- Dependency and lockfile changes deserve their own look.
- Automation catches patterns. Humans catch intent.
- Make the process enforceable with branch protection.
What should I look at first in a pull request?
Start with where untrusted input enters: request parameters, headers, files, messages, environment, and third-party responses. Then trace each one to the places it is used. Danger sits where input reaches a query, a shell, a file path, a template or a deserializer.
What is a practical secure review checklist?
- Input: is it validated, and is output encoded for its destination?
- Queries and commands: parameterized, never built by string concatenation?
- Authentication and authorization: does each new route check who is asking and what they may do?
- Secrets: any keys, tokens or passwords in code, tests or config?
- Errors and logs: do they leak personal data or secrets?
- Dependencies: new packages, version bumps and lockfile changes explained?
- CI files: workflow changes reviewed for permissions and script injection?
How do I review dependency changes?
Read the manifest and lockfile diff. Ask why each new package is needed, whether the name is exactly what you expect, and whether the version jump matches the manifest change. See how to pin dependencies and lockfiles for what to look for.
How do I make review enforceable?
Use branch protection. GitHub's protected branches can require a set number of approving reviews, require code owners to approve changes to their areas, dismiss stale approvals when new commits change the diff, and require status checks to pass before merging. Signed commits and linear history are optional extras.
Add CODEOWNERS entries for authentication code, CI workflows and dependency files.
Where does automation help?
Scanners find known patterns quickly, so reviewers can spend time on logic and design. A pull request gate runs checks before merge. Safeguard's interactive demo shows one:
Click through it at your own pace, or open it full screen.
Frequently asked questions
How long should a secure review take?
Keep changes small enough to review in under an hour. Large diffs get skimmed.
Can a scanner replace human review?
No. Scanners catch known patterns. People catch missing authorization and flawed logic.
Who should be required to approve?
At least one person other than the author, plus the code owner for sensitive paths.
Should reviewers check the CI config?
Yes. Workflow files control secrets and deploys, so review them like code.
Sources
Last reviewed: 19 October 2026.
