Add a human review when the decision depends on application rules, cross-service controls, deployment context or disputed evidence that an automated result does not establish. Prioritize changes at trust boundaries: who may act for an account, which tenant owns an object, where private data leaves a service, and what a new privileged workflow permits. Also review consequential scanner findings before handing them to developers as fact, and sample consequential “clean” results when the scan's scope or detection limits could conceal a missed path. The aim is a bounded decision with evidence, not a ceremonial approval on every pull request.
Automation can search broadly and consistently; a reviewer can ask whether the searched pattern represents the actual business rule. The two methods are complementary. NIST's Secure Software Development Framework, PW.7 explicitly considers code review by a person and code analysis by tools. The OWASP Secure Code Review Cheat Sheet identifies business logic, complex authorization and context-specific issues as valuable manual-review targets. Neither source promises that a human will find every vulnerability.
Route work by the question it asks
Make the review trigger explicit enough that developers know when to request help and security knows what to examine. Use this decision table as a starting policy, then adjust it after observing your own code and review capacity:
| Change or signal | Default route | Human question |
|---|---|---|
| Routine change inside an established, reviewed control pattern; automated checks complete for relevant scope | Normal code review plus configured checks | Has the change stayed inside the pattern and declared scope? |
| New or altered permission, tenant boundary, payment rule, sensitive export, secret handling or external integration | Targeted security review before release | What exact actor-to-effect path is possible, and where is it stopped? |
| Scanner flags a high-impact path or two tools/reviewers disagree | Independent finding review | What evidence supports or defeats the precise claim? |
| Scanner is clean but skipped files, timed out, used a narrow rule set or missed a changed trust boundary | Targeted review of that gap | Which rule or component was not actually examined? |
| Plausible active abuse or severe current exposure | Incident and containment route alongside verification | What must be contained now, and what remains unproven? |
This is a routing policy, not a scanner accuracy score. A “pass” only refers to the checks that ran over the stated scope. Source inspection is not an executed exploit, and a source-traced path may still need production route or configuration evidence. OWASP SAMM's Architecture Assessment practice calls for checking whether architecture actually provides relevant security mechanisms and mitigates identified threats. That is particularly useful when a control lives in a different service from the changed handler.
Walk through one illustrative change
Illustrative case, not a discovered customer vulnerability: Atlas Notes adds a bulk document-download endpoint. A signed-in user submits a list of document IDs. The automated scan finds no new alert; it examined the handler, but its reported scope did not include the document service or production route configuration. The feature's rule is more precise than “must be logged in”: a user may download only documents belonging to their current account and permitted workspace.
A reviewer requests the feature spec, the pinned revision, the handler call, the document-service read and the deployment mapping. She traces ordinary user → supplied ID list → handler → document service → archive response. The handler validates that the user is signed in. The service method accepts document IDs, but the first read shown in the code has no account or workspace predicate. A different single-document route has an ownership check; that does not prove the bulk path uses it. The reviewer asks whether the storage layer enforces ownership and whether this handler is deployed. Until those facts arrive, “cross-account disclosure” is a plausible, unverified claim, not a confirmed breach.
Her review note is small enough to act on:
Policy: Each requested document must belong to the caller's current account and an authorized workspace.
Scope: Bulk-download change at revision
b92d10; document service and production mapping requested.Supporting path: Authenticated user controls document IDs; handler passes them to archive builder.
Known control: Login check; single-document route checks ownership but is not called here.
Unknowns: Storage-layer authorization and deployed route binding.
Next owner: Document-service engineer supplies the read predicate; platform owner supplies route map.
Current decision: Hold the security sign-off for this new export path pending those facts. Do not file a confirmed disclosure ticket yet.
Continue with the missing service artifact. In this exercise, readMany(ids) loads documents before an account check that examines only the first returned document. The route is mapped to the new release candidate, not yet production. A mixed-account batch could therefore satisfy that first check while including another document. The single-document guard still does not protect this call.
The reviewer returns a bounded decision: “Do not release this bulk path until every returned document is constrained to the caller's authorized account and workspace. Preserve ordinary multi-document downloads. Source and release-candidate evidence support the gap; no production disclosure is asserted.” The acceptance note includes mixed-account batches in both orders, an all-foreign batch, and an ordinary same-workspace batch. Check the order actually returned by the data service; input order may not be preserved, so merely putting an allowed ID first in the request is not a reliable check of a first-result-only guard. Those are proposed controlled checks, not executed results. If the service instead required a compulsory account/workspace-bound query for every document, the conclusion would be a scoped rejection with that exact evidence.
Choose where the scarce reviewer hour goes
Now suppose the team has only one three-hour specialist slot tomorrow and four pending changes. A review trigger alone does not create four slots. Engineering and Product make this concrete allocation:
| Work awaiting attention | Immediate routing decision | What the specialist should answer |
|---|---|---|
| Text-only maintenance inside an established control | Ordinary owner code review; no new security slot | No new trust-boundary question identified |
| New bulk export above, release still held | Keep disabled; service owner prepares complete per-document enforcement evidence | Review the revised bulk contract in the next available slot |
| Severe scanner claim about an existing optional debug route; query binding is disputed | Incident/service owner restricts that route while evidence is collected; candidate remains unresolved | Whether the actual driver call treats the disputed input as syntax or data |
| Clean authentication refactor that skipped the shared session resolver | Use tomorrow's slot; release hold remains until review decision | Whether old sessions and account switching use the new resolver and retain current membership enforcement |
Why choose the clean refactor over the severe alert? The other two consequential paths have effective restrictions stipulated in this case, while the auth refactor changes a shared control and has an immediate release decision. That ordering would change if the debug restriction were not evidenced or a credible active-abuse report arrived. The incident response does not wait for tomorrow's appointment.
The specialist receives a narrow package: old and new session-resolution calls, account-switch flow, current-membership contract, failed scan scope, and release deadline. The deliverable is a decision on those paths with missing facts called out, not a three-hour promise to audit authentication. At the end, an incomplete decisive artifact keeps the release hold in place. Review capacity must remain connected to an action the organization can take.
Make the review executable in a busy team
Input: A change diff or alert, pinned revision, expected user action, affected service map, scan result and exclusions. The feature owner writes the intended authorization rule in one sentence. If the rule is missing, that is the first review task.
Action: A reviewer qualified for the specific question—such as the service engineer for a query contract or an identity specialist for session semantics—follows one actor-controlled input through entry, checks, downstream services and effect. Review the control that should defeat the harmful path, not only the flagged line. For a complex change, ask a second person to challenge the conclusion using the original evidence and counterevidence. A second signature on the same summary without independent inspection adds little.
Decision: Record one of four outcomes: no relevant gap found within the declared scope; issue independently supported and ready for an actionable finding; claim defeated by specific counterevidence; or inconclusive because a named artifact is missing. Preserve the revision and exact scope for all four. A human can be mistaken, so “no relevant gap found” is not “secure.”
Output: The reviewer writes a brief with the expected policy, traced path, supporting and defeating evidence, deployment assumptions, decision, owner and next check. The engineering manager can then schedule an evidence task or a fix. For a confirmed issue, the developer sees the concrete harmful action and the missing enforcement point rather than a generic scanner category.
Check: At the next revision, inspect the relevant control and alternate entry paths; where permitted, run a controlled validation of the expected allow and deny behavior. A new scanner result may help find regressions but cannot by itself prove that the original path is fixed.
Here is a copyable request format:
Review trigger and deadline:
Repository, immutable revision, changed component and deployment:
Expected actor, object and authorization rule:
Scanner run, rules, completed scope and exclusions:
Actor-controlled input -> entry -> controls -> effect:
Highest-impact plausible failure and counterevidence to inspect:
Missing config, owner or runtime fact:
Reviewer decision, evidence links, next owner and reassessment condition:
If no qualified reviewer is available, do not turn the review field green by assigning someone unfamiliar with the system. Narrow the release, preserve the review request, or take an explicit risk decision through the organization's authority. For an urgent suspected exposure, containment should not wait for a perfect source trace. For ordinary changes, review capacity is a planning constraint: sample lower-risk clean results and reserve deep review for changed trust boundaries and evidence disputes. Revisit the trigger list when missed issues or excessive review delays show that it routes work poorly.
Check whether the review answered the trigger
At the end of the specialist slot, compare the result with the reason the review was requested. For Atlas's bulk export, the question is whether every returned document satisfies the account and workspace rule. A general walkthrough of authentication or a list of scanner findings does not answer that trigger unless it reaches the per-document boundary.
The review output should identify the decisive artifacts inspected, the remaining unknowns and the release implication. If the revised service constrains every document correctly, record that property and its scope. If only the first result is checked, name the surviving gap. If the data-service implementation is still unavailable, record an incomplete review and an evidence owner rather than using time spent as proof of coverage.
Feed that result into the next review request. A recurring missing service artifact suggests improving intake; repeated confusion about the intended workspace rule suggests earlier product involvement. The trigger list should evolve from those concrete failures, not from a goal of sending every change through a specialist.
Take the next change that adds a permission or export path and fill the request format before its merge decision. For the method of challenging an individual alert, use the finding-triage worked guide. When the review supports a delayed repair, use the exception template rather than relabeling the issue resolved.