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 PR security review, live on install, 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, at most five 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, live on install 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.