You cannot review every change, and you should not try. At one security engineer per hundred developers the maths is settled before you start, and a process that requires you to look at everything produces a queue that becomes a rubber stamp.
The useful question is narrower: which changes are worth your attention, and how does a developer know to send you one without being a security expert.
This post is the trigger list and the process around it. For whoever is the review bottleneck.
Triggers, not judgement
Asking developers to "involve security when it seems relevant" fails in both directions: you get asked about copy changes and not asked about the new export endpoint, because relevance requires exactly the expertise the person does not have.
Give them a list of observable properties instead. A change triggers a review if it:
- Accepts input from a new source, including a new endpoint, a new file type, a new message consumer, a webhook, an inbound email path.
- Changes authentication or authorisation, including adding a role, a permission, a sharing mechanism, or an exemption.
- Handles a new category of data, particularly personal, financial or health data.
- Adds a third party: a new dependency with unusual reach, a new vendor, a new outbound integration.
- Changes network exposure: a new public endpoint, a new port, an ingress rule, a change to what is reachable from where.
- Touches credentials: issuing, storing, rotating, validating.
- Moves or copies data to a new place, including a new cache, index, warehouse or export.
- Modifies an existing control, including disabling one temporarily.
Every item is answerable by the person writing the code without knowing why it matters. That is the property that makes the list work.
Put it where the work happens
A checklist in a wiki is not a trigger. A short section in the pull request template is:
## Security
- [ ] New external input (endpoint, file, webhook, queue, email)
- [ ] Changes auth or permissions
- [ ] New data category, or data moved somewhere new
- [ ] New third party or dependency with network/file access
- [ ] Changes network exposure
- [ ] Touches credentials or a security control
- [ ] None of the above
Ticking a box notifies the reviewer. Ticking "none of the above" is a claim the author makes, which is both faster than asking and more accountable than silence.
Some of this can be automated. Changes to authorisation middleware, dependency manifests, infrastructure definitions and route files can notify automatically by path, which catches the cases people miss and reduces what the checklist has to carry.
Make the review short enough to be used
A review that takes a week gets routed around, and then you have no visibility at all, which is worse than a fast review that misses something.
Target a day for the common case. That is achievable if the review is scoped: what changed, what it touches, what could go wrong, and one or two specific questions back to the author. It is not achievable if every review becomes a full threat model.
Reserve the deeper exercise for the small number of changes that genuinely warrant it: a new authentication mechanism, a new tenancy boundary, a new external integration handling sensitive data. Perhaps a handful a year.
What the review should produce
Not approval. Approval creates a gate you become responsible for and a queue you cannot clear.
Produce findings and decisions: things to change before merge, things to change later with an owner, and things explicitly accepted. Write the accepted ones down, because an undocumented acceptance is indistinguishable from an oversight when someone reads the code in two years.
Then, where the finding is general rather than specific, push it into the defaults: a template, a lint rule, a library, a gate. A finding you fix once in a service template is a finding you never review again.
Track what you are not seeing
The number worth watching is not reviews completed. It is the proportion of qualifying changes that reached you.
Sample it: pick twenty merged pull requests at random each month and check how many should have triggered a review and did not. That tells you whether the triggers are understood, whether the checklist is being skipped, and which category is being missed. It is an hour a month and it is the only honest measure of coverage.
The concession
Trigger lists produce false positives, and a developer who ticks a box and waits for a reviewer who is busy learns not to tick the box. The process fails through response time far more often than through bad triggers.
So if you cannot respond within a day, shorten the list rather than the response. It is better to review three categories reliably than eight unreliably, because unreliable review teaches people that the process is optional, and that lesson is expensive to unlearn.
The implication
The bottleneck is not knowledge, it is attention, and the scarce resource is the reviewer's day rather than their judgement.
So spend the design effort on what reaches them: triggers a non-expert can evaluate, placed in the tool they already use, with a response fast enough that using it is easier than not.
