security-verdict-and-report

Security Verdict and Report

Overview

A security reviewer that blocks on noise gets ignored; one that passes on a hunch ships a breach. The verdict follows a fixed policy so the developer can predict it and the human can trust it.

Core principle: block only what you can prove is exploitable and new; say nothing about what you cannot.

1. Severity

Severity	Meaning	Typical examples
CRITICAL	Exploitable now with little or no precondition; full compromise	RCE, auth bypass, SQL injection on a public endpoint, a live production secret committed, a malicious dependency
HIGH	Significant, reachable, one realistic precondition	IDOR on another user's data, stored XSS, SSRF to an internal service, path traversal reading server files, pull_request_target running PR code with secrets
MEDIUM	Needs specific conditions, or real but bounded impact	CSRF on a state change, reflected XSS behind an unusual flow, user enumeration that enables a further attack, verbose error leaking internal paths
LOW	Defence in depth, best practice	Missing header with no vulnerability, weak-but-unused config

Exposure moves severity, not existence: "only reachable from the internal network" can still be HIGH when internal callers are not trusted. Use the deployment shape from get_project_brief.

2. Confidence

Confidence is about exploitability in this code, not about whether the pattern looks bad:

• 0.9–1.0 — you traced source → sink end to end and can write the exploit input.
• 0.8–0.9 — a known vulnerable pattern; source and sink both read; no guard found on the path.
• 0.7–0.8 — suspicious, but it needs a condition you could not confirm. Not reported.
• < 0.7 — not reported.

3. The Decision

Evaluate every surviving finding, then apply the strongest outcome:

1. Unreviewable — part of the change could not be read (unreviewable-never-passes) → need_revision, naming exactly what could not be verified.
2. Block → need_revision when any holds:
   • a CRITICAL or HIGH finding introduced or enabled by the diff, confidence ≥ 0.8, surviving the exclusions and the self-refute pass;
   • a live secret in non-test code;
   • a new or changed dependency that is malicious, a likely typosquat, or carries a critical/high advisory with a fixed version available;
   • CI or agent escalation: pull_request_target with a PR-head checkout and secrets in reach, an agent permission-bypass flag, untrusted input reaching an LLM that holds tools.
3. Approve with notes → ready_for_qa plus one comment: MEDIUM findings at ≥ 0.8, at most three, highest first.
4. Clean → ready_for_qa, no comment.