Adversarial Review

Adversarial Review

When to use

• Reviewing a pull request, patch diff, or proposed design.
• The user asks for a "critical review", "threat model pass", or "what could go wrong".
• Before merging high-risk changes (auth, payments, data deletion, public APIs).

When not to use

• Rubber-stamping typo/docs-only PRs where risk is negligible.
• Pairing sessions where the goal is collaborative drafting, not gatekeeping (switch to review mode when ready).
• Replacing formal security audit/penetration test engagements.

Assumptions

• Access to the full diff, linked issue, and ability to run or reason about tests.
• Product/security context may be incomplete — call out assumptions explicitly.
• Do not merge, push to protected branches, or dismiss required reviews without authorization.
• Do not exfiltrate secrets found in the diff; follow secrets-hygiene instead.

Workflow

1. Restate the change's purpose and trust boundaries in your own words.
2. Hunt for failure modes: nulls, races, authz gaps, injection, unsafe defaults, partial failure.
3. Check tests for gaps relative to those failure modes.
4. File concrete, severity-tagged findings (blocker / should-fix / nit).
5. Approve only when blockers are addressed or explicitly accepted by the owner.

Steps

1. Intent check — Does the diff match the claimed purpose? Flag unrelated churn.
2. Abuse cases — For each new input/surface: unauthenticated access, confused deputy, oversized payloads, replay, TOCTOU, and error-path leaks.
3. Defaults & footguns — Fail-open vs fail-closed; permissive CORS; debug flags; default passwords; broad IAM.
4. Data & teardown — Migrations, deletes, and retries: idempotency, backup/rollback, PII exposure in logs.
5. Test gaps — Map each serious risk to a missing test; demand or add coverage for blockers.
6. Report — Structured findings with file/line references and a clear merge recommendation.

Success criteria

• Review names specific failure modes, not only style nits.
• Missing tests for high-severity risks are called out.
• Unsafe defaults and authz edges are explicitly assessed.
• Findings are prioritized (blocker vs non-blocking).
• No unauthorized merge or secret leakage occurred during review.

Out of scope

• Full formal threat modeling workshops for an entire product.
• Legal/compliance sign-off.
• Rewriting the feature for the author unless asked.