/variant-analysis

name: variant-analysis
description: "Start from a confirmed bug and hunt its siblings: generalize the root cause (source, sink, missing guard), encode it as a static-analysis query with positive and negative test cases, or a non-destructive nuclei template for variants visible only over HTTP, run it across the codebase or the whole org, close every hit with a verdict linked to the original, and keep the check in CI so the bug class stays fixed. Use when the user mentions 'variant analysis,' 'find variants,' 'where else does this bug exist,' 'are there more bugs like this,' 'same bug in other routes,' 'custom semgrep rule,' 'semgrep --test,' 'ruleid annotation,' 'CodeQL query for this bug,' 'CodeQL query test,' 'nuclei template for this bug,' 'turn this bug into a check,' 'stop this bug class coming back,' or has a known bug and wants every other instance of it."
allowed-tools: Read, Grep, Glob, Write, WebSearch, Bash(semgrep --test --metrics=off .semgrep/variants/), Bash(semgrep --validate --metrics=off --config .semgrep/variants/), Bash(semgrep scan --metrics=off --config .semgrep/variants/ --exclude .semgrep --json --output .security/out/variants.json .)

Variant Analysis — One Bug In, Every Sibling Out

A confirmed bug is rarely alone. The developer who forgot the owner check on one route probably forgot it on two more, and the team that copied that handler copied the bug with it. This skill takes one confirmed finding, writes down why it's wrong, encodes that as a tested rule, runs the rule wherever the code lives, and closes every hit with a verdict linked back to the original.

Cross-references: `owasp-audit`, `api-audit` and `finding-triage` (where the starting finding usually comes from, and where a single hit goes for a disposition), `scanner-pipeline` (runs the finished rule on every PR and weekly), `patch-sweep` (fleet inventory and production branches when the rule runs across many repos), `web-pentest` (authorization before a nuclei template touches a live host), `vuln-research` (when the starting point is a published advisory rather than your own bug), `siem-detection` (rules over logs; this skill writes rules over code and HTTP responses).

**Why `Write` is pre-approved:** the main output is files: rule files, their test fixtures, and `findings.json`. The Bash grants are exact commands for `semgrep --test`, `semgrep --validate` and one fixed `semgrep scan`, because semgrep has `--autofix` and a prefix grant can't exclude a trailing flag (`scripts/grant-check.mjs`). Any other semgrep command, every `codeql` command (database creation and test runs write to disk) and every `nuclei` run prompt.

When to use

• "We found an IDOR in `/notes/:id`. Are there others like it?"
• A finding from `owasp-audit`, `api-audit`, a pentest report or a bug bounty, and the question is where else it occurs
• "Write a Semgrep rule (or CodeQL query) for this, with tests"
• A bug fixed once that keeps coming back, and you want CI to block it
• A bug only visible from outside (a header, a response field, an endpoint shape) that may exist on other hosts you own

Input: one confirmed finding. A `findings.json` record (best: it has the fingerprint, trace and location) or a described bug with a file and line. Read access to the repo, and the list of repos or hosts to search.

**Not for:**

• No bug in hand yet, just "find vulnerabilities" → `owasp-audit` or `api-audit`
• Running the standard scanners (gitleaks, osv-scanner, `p/default`) → `scanner-pipeline`
• Disposition of one finding ("is this real, what severity") → `finding-triage`
• Patching a CVE across every app → `patch-sweep`
• Sigma, KQL or SPL rules over logs → `siem-detection`
• Whether a published CVE reaches your code → `vuln-research`

Authorization

• **Code:** only repos the user owns or is authorized to review. For an org-wide run, get the list of owners or orgs; don't infer it from what a token can read.
• **Pre-approved:** writing rule and test files under `.semgrep/variants/`, `semgrep --test`, `semgrep --validate`, and the one scan in `allowed-tools`. They read the code and write only rule, fixture and report files.
• **Prompts every time:** `codeql database create` and `codeql test run` (they build databases on disk), any semgrep command with `--autofix`, cloning repos for a fleet run, and every `nuclei` run.
• **nuclei templates:** run only against hosts the user owns and names in this conversation, ideally staging, after `web-pentest`'s authorization step. Templates use GET/HEAD or requests that change nothing, with test accounts the user created. A template that writes, deletes, or reads real customer data is out of scope; prove the variant in code instead.
• **Refuse:** running a template or rule against third-party hosts or repos, turning a variant rule into an exploit, and adding autofix to a rule without the user reviewing every change.

Step 1 — Pin down the original

Write the root cause in one sentence that says **why** the code is wrong, not what it does. Then split it into three parts:

| Part | Question | IDOR example | |---|---|---| | **Source** | Where does attacker-controlled data enter? | `req.params.id` in an Express route | | **Sink** | Where does it do damage? | A row lookup or delete keyed on that value | | **Missing guard** | What should have stood between them? | An owner or tenant predicate tied to `req.user.id` |

From a `findings.json` record, take `trace[]` (entrypoint = source, sink = sink), `location`, and the `counterevidence` that often names what a sibling route does right. Keep the original's fingerprint; every variant links to it.

Then list where variants could hide, beyond the obvious copy-paste:

• **Same mistake, other sinks:** update and delete as well as read; export, download, and webhook-replay endpoints.
• **Same mistake, other APIs:** raw SQL, the ORM, a GraphQL resolver, a server action, a queue worker.
• **Same mistake, other inputs:** body field, query string, heade