security-review-feedback

name	security-review-feedback
description	Use when receiving a security review or vulnerability report — from an AI tool, a security-review command, or a human reviewer — and deciding which findings are real and worth fixing. Verify reachability, attacker control, and exploitability before implementing any fix; reject false positives and severity inflation rather than agreeing reflexively.

Security Review Reception

A security finding is a claim to verify, not an order to implement.

Core principle: every finding earns a verdict before any fix is written — TRUE POSITIVE, FALSE POSITIVE, or NEEDS-INFO. Prove reachability and impact with evidence; never assume them from how the code looks.

Security reviews — AI, command-driven, or human — fail the same way: false positives and severity inflation. AI reviewers especially over-flag ("this pattern looks dangerous") and overrate severity ("definitely critical") without tracing whether an attacker can reach or control the code. Implementing every flagged item churns code for issues that are unreachable or impossible.

Relationship to code-review-feedback

The reception posture is shared, not restated here. Load code-review-feedback for it: no performative agreement ("you're absolutely right"), no gratitude, push back with technical reasoning, clarify unclear items first, implement one at a time and test each.

This skill adds the security verdict layer on top: before the implement stage, every finding passes the verdict workflow.

The Verdict Workflow

FOR each finding in the review:
  1. RESTATE   the claim in your own words
  2. THREAT    establish the threat model
  3. TRACE     source → sink, and backwards for validation
  4. GATE      run the gate reviews
  5. VERDICT   assign verdict + calibrate severity
THEN:
  6. CHAIN     check whether rejected findings combine
  7. IMPLEMENT TRUE POSITIVEs only, highest severity first

1. Restate the claim

State the vulnerability, alleged root cause, trigger, and claimed impact in your own words. Half of false positives collapse here — the claim doesn't cohere when stated precisely. If you can't restate it coherently, verdict is NEEDS-INFO: ask the reviewer rather than guessing.

2. Establish the threat model

• What privilege level does this code run at? Is it sandboxed?
• What can the attacker already do before triggering the bug?
• Is the input attacker-controlled, or internal/trusted (config, compile-time constant, value set by a trusted component)?

A "vulnerability" reachable only by an already-root local user, or fed only by trusted internal data, rarely survives this step.

3. Trace source → sink

Confirm attacker-controlled data actually reaches the dangerous operation. Trace the full path step by step — don't assume network/user data arrives unmodified. Then trace backwards: find every validation, bounds check, and assertion preceding the sink. Vulnerable-looking code is often guarded upstream. Verify claimed guards (auth middleware, a "behind requireAdmin" comment) against the actual registration — don't trust the claim.

4. Run the gate reviews

A finding is a TRUE POSITIVE only if it passes every applicable gate. The first gate it fails makes it a FALSE POSITIVE, recorded with the evidence.

Gate	Passes when	Fails when
Reachability	A concrete execution path reaches the code under attacker-influenced inputs	The path is unreachable, dead, or test/debug-only
Attacker control	The attacker controls the data that drives the bug	The input is internal, trusted, or fixed
Real impact	Leads to RCE, privilege escalation, or information disclosure	Only an operational-robustness issue (a crash of non-critical, restartable work)
Math / bounds	The vulnerable condition is arithmetically possible given the validation	Validation makes the condition impossible (e.g. underflow can't occur)
Environment	Platform/runtime protections do not fully prevent exploitation	A sandbox, framework, or language guarantee blocks it entirely

5. Assign a verdict + calibrate severity

Don't adopt the reviewer's severity uncritically — re-derive it from impact × reachability. An unauthenticated, trivially reachable RCE is critical; the same bug behind three privilege checks is not. AI reviewers systematically over-rate; a finding that survives the gates but needs improbable preconditions is low, not critical.

Rationalizations to Reject

If you catch yourself thinking any of these, STOP.

Rationalization	Why it's wrong	Required action
"This pattern looks dangerous, so it's a vuln"	Pattern recognition is not analysis	Trace the data flow before concluding
"This is clearly critical"	AI reviewers are biased toward bugs and over-rate them	Prove impact and reachability with evidence
"Similar code was vulnerable elsewhere"	Each context has different callers and protections	Verify this instance independently
"Skip the trace, the fix is cheap anyway"	Cheap fixes still churn code and can mask the real path	Run the full workflow; a no-op fix is still a no-op
"The reviewer is an expert, just implement"	Source authority does not establish a finding's truth	Verdict before fix, regardless of source

Verdict Output Format

One line per finding, then act only on the confirmed set:

FINDING #1 TRUE POSITIVE  — SQL injection in search handler; user query reaches raw concat (sink: db.go:88)
FINDING #2 FALSE POSITIVE — Integer underflow in parser: Math/bounds gate fails — length validated >= 16 at line 40, so (length - 8) cannot underflow
FINDING #3 NEEDS-INFO     — "auth bypass in middleware": cannot identify which middleware or which route; ask reviewer to point at the code path

Then implement TRUE POSITIVEs only, highest severity first, one at a time — the how of responding and fixing lives in code-review-feedback.

Exploit Chains

After per-finding verdicts, check whether findings that individually failed a gate combine into a viable attack — e.g. an info-disclosure that leaks the address a separately-rejected overflow needs. A chain can be a TRUE POSITIVE even when its links are not.

Before Issuing a FALSE POSITIVE

Apply the full checklist in false-positive-patterns.md before finalizing any FALSE POSITIVE verdict. A rejection is a claim too, and must be evidenced.

The Bottom Line

A security review = claims to verify, not fixes to apply.

Verdict before fix. Evidence over pattern-matching. Re-derive severity. No reflexive agreement, whatever the source.