variant-huntlisted

# Variant Hunt The single most common failure in code security is fixing the bug you were shown and missing its siblings. The developer who wrote an unsafe query at one place wrote it the same way in six others — it's a habit, not an accident. A review that fixes one and stops leaves the codebase almost as exposed as before. This skill exists to make that failure impossible. Given one confirmed finding, it sweeps the whole codebase for the same pattern and reports every instance, so the *class* is eradicated, not just the instance. ## When to reach for this skill The moment a vulnerability or bug is confirmed — by a scanner, a review, or an incident. Also when verifying that a fix is complete ("did we get all of them?"), or when someone needs proof that a known-bad pattern from a past incident no longer exists anywhere. If you just found or fixed a security issue and haven't swept for variants, you're not done — that's the trigger. ## The method ### 1. Characterize the pattern Reduce the finding to its root shape — the thing that makes it dangerous, stripped of the specifics of this one location. Examples: - "user input concatenated into a SQL string" - "an object fetched by id with no ownership/tenant check" - "a secret compared with `==` instead of a constant-time function" - "a user-supplied URL fetched server-side without allowlisting" The sharper the characterization, the better the hunt. Name the **sink** (the dangerous operation) and the **source** (untrusted i