adjudicating-taint-paths

name	adjudicating-taint-paths
description	Decide whether a whitebox lead is a real bug by tracing taint from an untrusted source to a dangerous sink and confirming every hop against live source. Use after a scanner, a candidate list, or your own reading surfaces a "this looks dangerous" sink (SQL exec, system/exec, file open, deserialize, template render, redirect target, memcpy) and you must decide whether attacker- controlled input actually reaches it - or kill the lead with evidence. Covers forward and reverse taint, witness paths, sanitizer analysis, and the evidence rules that separate a finding from a false positive.
license	MIT

Adjudicating taint paths: lead → decided finding

A lead is a fact about structure - "an input-shaped value can reach a dangerous sink." It is never a verdict. Adjudication is the disciplined work of deciding whether that structural possibility is a real, reachable bug on the current source, and recording the decision so it isn't re-litigated next pass.

When to use

• A scanner or candidate list flagged a sink and you must confirm or kill it.
• You spotted a sink by hand and want to know if attacker input reaches it.
• You need to kill a plausible-looking lead with evidence, not vibes.

Scope check

Authorized source only (your own, OSS, CTF, in-scope engagement). If you can't name the authorization, stop.

The loop

1. Name source and sink precisely. Which exact argument of which sink is dangerous, and what is the actual untrusted entry - a request param, header, filename, env var, deserialized field? Vague framing ("user input reaches it somewhere") is how false positives survive.

2. Trace the reverse cone into the sink. What values can flow this sink argument? This enumerates every origin. If none trace back to an untrusted source, the lead is dead - kill it, record why.