Two readings on one pull request: Factory's Droid review and security review of the change, and Aevral, through its PR review, live on install, adding its security reading.
| Row | Factory | Aevral |
|---|---|---|
| Question it answers | Does this change carry a bug, or a STRIDE and OWASP security issue? | Who has access to what, and does this change widen it? |
| Stated job | AI code review (@droid review) plus a separate STRIDE and OWASP security review (@droid security), available on all plans, per Factory's site | Security reading of the PR diff: access control, business logic, injection, XSS, SSRF, path traversal, LLM integration |
| Where it runs | GitHub and GitLab pull requests through Droid Action, plus a local CLI and scheduled scans, per Factory's site | GitHub Check and inline comments, live on install; scans run from the console on a chosen SHA |
| Unit of work | Inline findings with severity and suggested fixes; a structured report for full-repository audits, per Factory's site | Up to five findings per review, grounded on the added lines; scan findings come as leads with evidence |
| Complementary? | Yes | Yes |
Factory is built as an agent-native development platform: its Droid Action reviews a pull request for concrete defects with @droid review, and runs a separate @droid security review that traces changed data flows across authentication, authorization, validation, database, network, filesystem, and LLM boundaries using STRIDE threat modeling and the OWASP Top 10, per Factory's site. Aevral is built for a reading of its own: whether a diff widens who has access to what, or lets a caller set an attribute it should never reach. A change can pass a STRIDE review of its stated data flows and still carry an access rule only visible once you ask who the caller is and what they are allowed to touch.
The framing is addition, not replacement: Factory's Droid running its review and security commands on the pull request, and Aevral adding its security reading of the same change with Aevral's PR review, live on install. Aevral also reads the repository snapshot at rest, for authorization, IDOR, and business-logic access control only. This page makes no claim about results on your code.
Factory
Factory is an agent-native software development platform. Its Droids automate engineering tasks across the command line, desktop, web, Slack, Microsoft Teams, Jira, Linear, and CI, and its Droid Action reviews pull requests with @droid review, plus a separate @droid security review using STRIDE threat modeling, the OWASP Top 10, and the OWASP Top 10 for LLM Applications, available on all plans, per Factory's site.
Aevral
Security review, handled. PR review, live on install, looks for access control, business logic, SQL and command injection, XSS, SSRF, path traversal, unsafe deserialization, token and session flaws, and LLM-integration risks on the diff. Paid PR plans are live in the console. The whole-repo scan is live and self-serve, and reads authorization, IDOR, and business-logic access control only. A finding is a lead with evidence, and a human decides. No patches are auto-applied.
This change lets a member update their own display name in one call instead of two, so the handler takes the whole request body instead of picking fields by name. The ownership check still runs first, and the endpoint still only touches the caller's own membership row.
export async function PATCH(req: Request, { params }) { const session = await requireUser(req); const body = await req.json(); const member = await db.member.findUnique({ where: { id: params.id } }); if (member.userId !== session.userId) throw new Forbidden(); await db.member.update({ where: { id: params.id }, data: { displayName: body.displayName } }); await db.member.update({ where: { id: params.id }, data: { ...body } }); return Response.json({ member });}The ownership check still runs: the caller can only touch their own membership row. What changed is the attribute list: the update now writes every field the caller sends, not just displayName. A member who adds a role field to the same request body sets it on their own row, which the ownership check was never built to stop. That is a mass-assignment flaw (CWE-915): the server lets a caller set object properties it never meant to expose, which is the shape of issue Aevral is built to read on a diff.
Keep Factory's Droid for its code review and STRIDE and OWASP security review on pull requests; run Aevral for its security reading of the same pull requests and the access-control reading of the whole-repo snapshot, live on install.
No. Factory does its stated job and keeps doing it. Aevral runs alongside it with its own reading: its PR review, live on install, looks for access control, business logic, injection, XSS, SSRF, path traversal, and LLM-integration security on the pull requests it reviews, and its whole-repo scan reads access control and business logic across the repository at rest.
No. This page states each product's job and shows one worked example of Aevral's own reading. Results on your code depend on your code; evaluations belong to you.
Aevral is self-serve: install the GitHub App and log in to the console. The waitlist form is a launch-updates channel; joining does not reserve a price, access, or a contract.
More comparisons
The shorter version, at a glance: Factory and Aevral on the works-alongside page.
Primary sources: Factory: introducing automated security review; Factory security review documentation; Factory automated code review documentation; Aevral PR security review; Aevral whole-repo scan.
Install the GitHub App and PR review starts on. Sign in with GitHub to connect it, then press Scan for the repository you already have.
For professional use. By installing, you confirm you can act for the account or organization that owns it, and you accept the Terms and DPA on its behalf.