Build vs buy: a security review for pull requests

What building costs, past the first week

Writing the first version is the cheap part: one afternoon for a rule that catches the exact pattern you just fixed. The cost shows up after, in three places.

Someone has to tune it when it fires on code that is actually fine, or the team mutes it the way any noisy check gets muted.

Someone has to update it when the codebase grows a second way to write the same bug, because a pattern rule only knows the shape it was given.

And someone has to own it after the author leaves the team, which in practice means nobody does, and the rule goes stale while the repository keeps changing under it.

None of that is a reason not to build one. A rule for a pattern your team keeps getting wrong, in code you control, aimed at a bug class you understand well, is often worth the afternoon.

The honest accounting is that the afternoon is not the real cost; the maintenance is.

What buying costs

Aevral's PR security review is priced per organization, not per seat. Free covers 25 private reviews a month.

Starter is $49 for 100 reviews a month, Pro is $199 for 500 reviews a month, Business is $999 for 3000 reviews a month, Scale is $1,999 for 6500 reviews a month.

Public repositories are free, 500 reviews per organization per month. Prices exclude VAT and other taxes.

The review itself is a Check on the head commit plus inline comments on the added lines, at most five findings per review, advisory and never blocking a merge.

Findings are leads with evidence, not confirmations, and nothing is applied or merged for you. The maintenance cost moves from your team to the vendor; the review cost moves from zero to a monthly line.

A worked example of the maintenance gap

Picture a team that writes one GitHub Action rule after an incident: flag any new database query missing a workspace_id filter, matched by a regex over the SQL string. It works for a month.

Then a teammate rewrites the query builder to use a method-chained filter instead of a raw string, for an unrelated reason, and the regex stops matching anything. The rule is still green.

Nobody removed it; it just stopped doing its job, and no one notices until the next incident.

A diff-level access reading does not avoid that failure mode by being smarter about regexes. It avoids it by reading the actual call for the gate, on every pull request, instead of matching a string shape someone wrote down once.

That is the mechanism difference the SAST-vs-PR-review guide covers in full; this page is only about who pays to keep either approach current.

What this page does not claim

It does not claim a custom rule cannot work, and it does not put a dollar figure on either side, because that number depends on your team's pay and incident history, and inventing one would be a guess dressed as data.

It does not claim a catch-rate for either approach. The honest version of this decision is about who owns the maintenance, not a number.