Security Reviewer

#What the Security Reviewer reviews

The Security Reviewer is the second mandatory reviewer in /synthex:review-code/synthex:review-code. It complements the Code Reviewer with a vulnerability-focused lens — the two run in parallel on every diff, and both must clear the configured severity threshold before merge.

Concretely, the Security Reviewer assesses:

• Vulnerability classes. Injection (SQL, command, prompt), XSS, SSRF, deserialization, path traversal, IDOR, rate-limit bypasses. The OWASP Top 10 in practice.
• Input validation. Does the diff trust input it shouldn't? Are bounds checked on array indices, sizes, and counts? Are user-controlled strings escaped at the right boundaries?
• Secret handling. Are secrets read from environment / vault, never hard-coded? Are they ever logged, returned in errors, or sent to client telemetry? Are rotation paths intact?
• Authorization paths. Does the diff bypass an authz check the surrounding code relies on? Are admin-only paths gated? Are tenancy boundaries enforced where the data model has multiple tenants?
• Dependency risk. New packages: are they actively maintained, do they pin versions appropriately, are there known advisories?
• Cryptographic correctness. When the diff touches crypto (signing, hashing, encryption), is it using the right primitive at the right strength, and is the implementation stock rather than rolled-from-scratch?

#What it explicitly does not do

• Code-quality concerns. Maintainability, convention adherence, refactoring opportunities — that's the Code Reviewer's lens. The two are scoped intentionally.
• Performance. Even when "performance" interacts with security (e.g., DoS via algorithmic complexity), the Security Reviewer defers to the Performance Engineer if one is in the roster.
• Threat modelling at the system level. The reviewer is scoped to the diff under review. Cross-system threat analysis is a separate exercise — typically captured in a docs/specs/security.md spec the reviewer can reference, not invented per-PR.

#Severity calibration

The Security Reviewer's severity calibration is intentionally conservative — security findings tend to under-cluster (a low-severity bug in a sensitive context is high-severity in context). When the reviewer is uncertain, it errs toward higher severity, with the rationale explicit so the Tech Lead or user can downgrade if appropriate.

A typical finding:

### Finding — high: User-controlled input flows into sql template literal

**Location:** `app/api/search/route.ts:31`
**Category:** sql injection

The handler interpolates `req.query.q` directly into a tagged template that ends up as a
plain SQL string when passed through this client. Any client can issue
`/api/search?q='; DROP TABLE users--` and execute arbitrary SQL.

**Suggested change:**

  // Use the parameterized form the ORM exposes:
  const rows = await db.query(sql`SELECT * FROM items WHERE name LIKE ${'%' + q + '%'}`);
  // Or escape explicitly:
  const rows = await db.unsafeRaw('SELECT * FROM items WHERE name LIKE $1', [`%${q}%`]);

#When the Security Reviewer disagrees with the Code Reviewer

This is high-signal. The two reviewers run independently; when they disagree on whether a finding is real or how severe it is, the Findings Consolidator preserves both verdicts. The Tech Lead surfaces the disagreement to you rather than silently picking a side.

Disagreement usually resolves into one of three outcomes:

• The Code Reviewer was right and the Security Reviewer was over-eager — adjust severity.
• The Security Reviewer was right and the Code Reviewer missed a vulnerability class — patch the diff.
• Both have a point but on different aspects of the same change — split into two findings, patch separately.

The system is designed to expose this disagreement rather than hide it. That's the point of running two reviewers in parallel.

#Multi-model option

For high-stakes diffs (anything touching auth, payments, persistence, or external service integration), enabling the multi-model review pipeline is worth the extra cost. Different model families have different security blind spots; running multiple in parallel catches issues any single family would miss. Configure via code_review.review_loops in .synthex/config.yaml and the multi-model adapter list.