Variant Analysis

Before searching, deeply understand the known bug:

• What is the root cause? Not the symptom, but WHY it's vulnerable
• What conditions are required? Control flow, data flow, state
• What makes it exploitable? User control, missing validation, etc.

Step 2: Create an Exact Match

Start with a pattern that matches ONLY the known instance:

rg -n "exact_vulnerable_code_here"

Verify: Does it match exactly ONE location (the original)?

Step 3: Identify Abstraction Points

Step 4: Iteratively Generalize

Change ONE element at a time:

1. Run the pattern
2. Review ALL new matches
3. Classify: true positive or false positive?
4. If FP rate acceptable, generalize next element
5. If FP rate too high, revert and try different abstraction

Stop when false positive rate exceeds ~50%

Step 5: Analyze and Triage Results

For each match, document:

• Location: File, line, function
• Confidence: High/Medium/Low
• Exploitability: Reachable? Controllable inputs?
• Priority: Based on impact and exploitability

For deeper strategic guidance, see METHODOLOGY.md.

Tool Selection

Key Principles

1. Root cause first: Understand WHY before searching for WHERE
2. Start specific: First pattern should match exactly the known bug
3. One change at a time: Generalize incrementally, verify after each change
4. Know when to stop: 50%+ FP rate means you've gone too generic
5. Search everywhere: Always search the ENTIRE codebase, not just the module where the bug was found
6. Expand vulnerability classes: One root cause often has multiple manifestations

Critical Pitfalls to Avoid

These common mistakes cause analysts to miss real vulnerabilities:

1. Narrow Search Scope

Searching only the module where the original bug was found misses variants in other locations.

Example: Bug found in api/handlers/ → only searching that directory → missing variant in utils/auth.py

Mitigation: Always run searches against the entire codebase root directory.

2. Pattern Too Specific

Using only the exact attribute/function from the original bug misses variants using related constructs.

Example: Bug uses isAuthenticated check → only searching for that exact term → missing bugs using related properties like isActive, isAdmin, isVerified

Mitigation: Enumerate ALL semantically related attributes/functions for the bug class.

3. Single Vulnerability Class

Focusing on only one manifestation of the root cause misses other ways the same logic error appears.

Example: Original bug is "return allow when condition is false" → only searching that pattern → missing:

• Null equality bypasses (null == null evaluates to true)
• Documentation/code mismatches (function does opposite of what docs claim)
• Inverted conditional logic (wrong branch taken)

Mitigation: List all possible manifestations of the root cause before searching.

4. Missing Edge Cases

Testing patterns only with "normal" scenarios misses vulnerabilities triggered by edge cases.

Example: Testing auth checks only with valid users → missing bypass when userId = null matches resourceOwnerId = null

Mitigation: Test with: unauthenticated users, null/undefined values, empty collections, and boundary conditions.

Resources

Ready-to-use templates in resources/:

CodeQL (resources/codeql/):

• python.ql, javascript.ql, java.ql, go.ql, cpp.ql

Semgrep (resources/semgrep/):

• python.yaml, javascript.yaml, java.yaml, go.yaml, cpp.yaml

Report: resources/variant-report-template.md

Limitations

• Use this skill only when the task clearly matches the scope described above.
• Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
• Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.