Which diffs deserve a human security review

20.05.20263 min readAtalaia team

Teams that try to add a security review to every pull request usually stop within a month. The queue grows, reviewers skim, and the label becomes a formality. The opposite failure is just as common: nobody with security context sees the change that rewrote session handling.

The answer is routing. Most diffs carry little security risk. A few carry most of it. If you can name those few by path, you can send them to the right reviewers automatically and leave the rest to normal peer review and scanners.

What deserves a human

Scanners such as Semgrep and Gitleaks are good at patterns: a dangerous function, a hard-coded token, a known-bad dependency. They are poor at logic: whether this endpoint checks the right owner, whether this refactor removed a check, whether this new role is too broad. Human review is worth its cost where logic decides security.

The paths that usually qualify:

• Authentication and sessions. Login, token issuing, password reset, MFA, session storage.
• Authorisation. Policy code, role definitions, middleware that checks ownership.
• Cryptography. Anything that signs, encrypts, hashes passwords or generates tokens.
• Parsers and file handling. Uploads, deserialisation, archive extraction, URL fetching.
• Money and limits. Payments, balances, quotas, rate limits.
• Infrastructure as code. IAM policies, network rules, public buckets.
• CI and deploy config. Workflow files, deploy scripts, environment definitions.

Your list will differ. Start from your threat model: the code paths linked to your most important abuse goals are the ones to route.

Route it with CODEOWNERS

On GitHub, a CODEOWNERS file maps paths to required reviewers. Combined with branch protection that requires code owner approval, it makes routing automatic. A sketch for a typical service repository:

# .github/CODEOWNERS
# Default: the owning team reviews everything
*                               @example-org/payments-team

# Security-sensitive paths also need a security reviewer
/src/auth/                      @example-org/payments-team @example-org/appsec-reviewers
/src/authz/                     @example-org/payments-team @example-org/appsec-reviewers
/src/crypto/                    @example-org/appsec-reviewers
/src/uploads/                   @example-org/payments-team @example-org/appsec-reviewers
/infra/iam/                     @example-org/platform @example-org/appsec-reviewers

# Pipeline and ownership rules are themselves sensitive
/.github/workflows/             @example-org/platform @example-org/appsec-reviewers
/.github/CODEOWNERS             @example-org/appsec-reviewers

Two details matter. Later rules override earlier ones for the same path, so put the broad default first. And protect the CODEOWNERS file itself, or anyone can remove a rule in the same pull request that needs it.

Who the reviewers are

"appsec-reviewers" does not need to be a security team. In most organisations it works better as a group of security champions: one or two developers per area who have had some training and know the threat model for their part of the system. They review with domain context a central team cannot match.

Give them a short checklist for routed reviews, so the review has a shape:

1. Is every new entry point authenticated, and does it check ownership of the object it touches?
2. Did the change remove or bypass an existing check?
3. Is untrusted input validated where it is used, not only where it arrives?
4. Are secrets, tokens and keys handled through the approved library or store?
5. Are errors and logs free of sensitive data?
6. Does the change alter a trust boundary in the architecture diagram?

Beyond paths

Paths catch most cases, but not all. Some risky changes live in ordinary files. Two cheap additions help:

• Labels by content. A workflow can add a needs-security-review label when a diff touches patterns such as new routes, new dependencies or permission changes, and a ruleset can require the right review for that label.
• Self-declaration. A checkbox in the pull request template: "This change affects authentication, authorisation, payments or data exposure." Authors usually know.

Keep the routed volume low enough that reviewers read every diff. If the queue grows, tighten the paths rather than letting reviewers skim. A routed review that takes a day to start will be bypassed, so agree a response time with the reviewer group and keep it.

What to do on Monday

1. List the five to ten directories in your main repository where a bug would be a security incident.
2. Create a reviewer group of two or three people who know those areas.
3. Add the paths to CODEOWNERS, including the workflows folder and the file itself.
4. Turn on "Require review from Code Owners" in branch protection or rulesets.
5. After a month, count the routed pull requests and adjust the paths so the load stays reasonable.

Where this sits on the line

In the tower (in development):