Is Aevral SAST?
No. Aevral is an AI security review with mechanical gates, not a rules engine. The honest answer is two-directional, because rule-based SAST does things Aevral does not, and Aevral reasons about things rules cannot express.
The comparison, both directions
| Dimension | Aevral PR review | Rule-based SAST |
|---|---|---|
| Detection | An AI reads the diff plus head context and traces entry point to sink across files | Rule and dataflow matching over the whole tree, including community and custom rulesets |
| Cross-file authorization, IDOR, tenant scoping | Core scope: the missing control is named in the finding | Expressible only via bespoke rules per codebase; generic rules rarely catch it |
| Business logic (replay, quota, state machine, removed checks) | In scope, including security controls a pull request deletes | Effectively out of reach of pattern rules |
| Injection, XSS, SSRF, traversal, deserialization | In scope, evidence-gated, probabilistic | Mature, exhaustive, near-free; keep it |
| Secrets, dependencies, headers, memory corruption | Explicitly out of scope, never reported | Core SAST and SCA territory |
| Whole-repo and history reach | No: the review reads the diff of changed files plus head content of security-critical ones | Yes, on every push and on demand |
| Determinism | No: run-to-run results vary, and misses are published | Yes: same input, same findings |
| Noise posture | Diff-proven-only publication, verbatim grounding on added lines, silence on clean, unverified tier listed but never posted | Depends entirely on the ruleset; noise is the known failure mode engineers tune away |
| Speed and cost | Seconds to a minute per pull request, at model cost | Seconds, effectively free per run |
Rule-based SAST described by its stated job (for example Semgrep: rule and dataflow matching, in the editor, CLI, and CI). Each tool's own published scope: the works-alongside hub.
Keep both
Keep both. A rules engine such as Semgrep scans the whole tree deterministically, in seconds, and covers secrets, dependencies, and memory classes Aevral deliberately refuses. Aevral reads each pull request like a security engineer would, reasons across files about who can reach what, and must prove each claim on a line the pull request actually added before it says anything. The two overlap on injection classes; they do not replace each other.
What Aevral publishes is a lead with evidence, advisory, never a merge block. Measured behavior, misses included, is public on the receipts page. The mechanics of one review, including the grounding gate and the hard limits as numbers: the how-it-reviews page and the documentation site. How Aevral reviews a PR, Receipts, and the full mechanics on the documentation site.
Common questions
- Does Aevral replace the SAST I already run?
- No. Keep your SAST for exhaustive rule coverage, secrets, dependencies, and determinism. Aevral covers cross-file authorization, business logic, and identity classes on the diff, which pattern rules cannot express. Works-alongside pages state each tool's published job: the checks hub.
- Does Aevral grep or run rules?
- No. There are no rulesets. Three AI specialist passes read the packed diff and head context, and every published finding must ground on lines the pull request actually added, verified mechanically against the diff. A quote that does not match discards the finding, even a real one.
- Is it deterministic like a scanner?
- No. Runs vary, misses happen, and both facts are public. The gates around the model (the publication contract, the grounding check, the proof-required verdict, the cap of five) are deterministic and live in code. The detection itself is probabilistic.