false-positive-gate

False-Positive Gate

Overview

Reviewers — language models especially — are biased toward seeing vulnerabilities and toward rating them higher than they are. A pattern that looks dangerous ("string concatenated into a query", "path from a variable") is a candidate, not a finding. Every false block costs a developer round-trip and teaches the team to skim your comments; that is how the real one gets missed.

Core principle: try to kill each finding before you write it. What survives an honest attempt is worth blocking on.

1. Restate the Claim

Write it in one sentence, concretely: "An unauthenticated caller can send name=../../etc/passwd to GET /export and read any file the server can read." Many candidates collapse here — you cannot name who sends what to where, or the sentence is obviously not true once written down.

2. Five Conditions — All Must Hold

1. Reachability. The attacker controls the data at the source. Trace it: a value from config, an environment variable, a CLI flag, a constant, a server-generated id or an admin-only form is not attacker input for the user-facing threat model.
2. Real impact. Reaching the sink produces code execution, privilege escalation, data disclosure or integrity loss for someone other than the attacker. A crash, a 500 or an ugly log line is a bug, not a vulnerability.
3. A concrete exploit. You can write the request, the payload or a unit test that would demonstrate it. If you cannot, the confidence is below 0.8.
4. The bounds hold. Length limits, type coercion, an integer parse, an enum switch, a regex anchor, a UUID format check — read them; one of them often makes the payload impossible.
5. No environment control fully blocks it. A framework default (auto-escaping, parameter binding, CSRF middleware), a gateway rule visible in the repo, a network policy. Read it — "probably the WAF catches it" is not an argument either way.

3. Triage Dismissals

Drop the candidate when:

• No threat model fits. You cannot complete "an attacker with [capability] can [action] → [impact]".
• Exploit from the heavens. It needs a capability that already equals the impact: "an attacker who can edit the server's config file can make it run commands".
• Not in actual usage. The vulnerable function has no caller reachable from input (grep_code the symbol) — unless this diff adds one.
• Documented, intended behaviour. An admin tool that runs admin-supplied SQL; a CLI that reads the path its user gives it.
• The cure is worse than the disease. Hardening that would break the feature for a theoretical gain.
• A CVE number alone. An advisory against a library is evidence only when the vulnerable function or configuration is actually used here (supply-chain-and-dependency-review).