targeted-vuln-analysis
Targeted Vuln Analysis
Why This Exists
The default behavior when asked to "find vulnerabilities in this code" is breadth-first hallucination: scan every file, pattern-match against known CWE classes, and produce a long list of theoretical possibilities. This fails for two reasons:
-
Broad prompts invite broad answers. The model pattern-matches common bug classes even when they are not possible in the code's actual context. You end up reviewing theoretical vulnerabilities in code paths no attacker could reach.
-
Without depth, nothing is proven. A finding that says "this function concatenates user input into SQL" is a pattern match. A finding that traces the exact path from HTTP request → parameter extraction → string concatenation → query execution, demonstrates that no sanitizer exists on that path, and shows the concrete payload that exploits it — that is a vulnerability. The first is noise. The second is actionable.
This skill enforces depth-first analysis: pick a specific attack surface from the threat model, go deep on it, prove or disprove exploitability, and only then move to the next surface. Never scan broadly.
The Rule
Every finding must be PROVEN exploitable through an actual traced code path, or explicitly marked as unconfirmed/theoretical. "This pattern looks vulnerable" is never acceptable as a finding. Either trace the full path and prove it, or don't report it.