PR security review and SAST are different questions

The two questions

A SAST pass asks whether the code matches a known vulnerability pattern or dataflow hazard: the flaw classes its rules and engines are built around. A diff-level access reading asks whether this change widens who has access to what: the gate that disappeared, the tenant binding that moved, the reference the caller now names. The questions are orthogonal in practice, because clean-as-pattern code can still rewrite an access rule.

Where each fits in the pipeline

SAST passes run where you build, on every change, against their rule set. Aevral's opt-in PR security review add-on runs on the pull-request events that produce new code: opened, reopened, and synchronize. Each new head gets a fresh review, and the same head is never reviewed twice on the billing ledger.

The output shape is deliberately small: an advisory Check on the head commit plus inline comments pinned to the added lines, hard max two findings per review, never blocking a merge. It is a signal that respects the review budget, not a gate that respects nothing else.

What a good diff finding looks like

Grounded on added lines, because the author's diff is what they are answerable for. Carrying evidence, because a finding without the file and lines is a rumor. Naming the access rule in question, because the fix is to restore the rule, not to appease a pattern. Those three properties are what make a PR review finding actionable in the two minutes an author will give it.

Keep both

Nothing here says a team should run one instead of the other. The compare pages carry the full boundary per tool with worked examples, and the works-alongside pages carry the at-a-glance version. The honest stack runs both and spends the saved attention on the findings that need a human.