Find Similar Vulnerabilities Across Your Codebase

Helps find variants of an already-identified vulnerability or bug across a codebase, using a five-step process: first understand the original issue's root cause (not just its symptom - what conditions, control flow, and data flow made it exploitable); then write a search pattern (ripgrep, Semgrep, or CodeQL) that matches exactly the one known instance and verify it matches only that location; then identify which elements of the pattern can be abstracted (function names only if the pattern applies to a whole family, never variable names - use metavariables, literal values only if any value triggers the bug, arguments as wildcards if position doesn't matter) versus which must stay specific; then iteratively generalize one element at a time, reviewing every new match as a true or false positive after each change and reverting if the false-positive rate gets too high; and finally triage every match with its location, confidence (high, medium, or low), exploitability (is it reachable, are inputs attacker-controlled), and priority.

Use it after a vulnerability has already been found and needs searching for similar instances, when building or refining CodeQL/Semgrep queries for a security pattern, when performing a systematic code audit after an initial discovery, or when analyzing how one root cause manifests across different code paths. Do not use it for initial vulnerability discovery, general code review with no known pattern to search for, writing fix recommendations, or understanding unfamiliar code from scratch - those need different, dedicated approaches. Stop generalizing a pattern once the false-positive rate exceeds roughly 50% - that means it has gone too generic. This is authorized-use-only tooling: it requires explicit, written permission and a stated scope from the system owner before running anything that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a real target, and it stays read-only and defensive-only without that explicit, in-conversation confirmation.

Input is the original known vulnerability (its root cause and an exact code excerpt) plus the target codebase. An exact-match search starts the process:

rg -n "exact_vulnerable_code_here"

Output is a triaged list of candidate variant locations, each with file/line/function, a confidence rating, an exploitability assessment, and a priority, following the template in resources/variant-report-template.md. Ready-to-use CodeQL query templates (python.ql, javascript.ql, java.ql, go.ql, cpp.ql) and Semgrep rule templates (python.yaml, javascript.yaml, java.yaml, go.yaml, cpp.yaml) are provided per language under resources/.

Uses ripgrep for quick surface searches with zero setup, Semgrep for simple pattern matching or on code that doesn't build, Semgrep's taint mode or CodeQL for tracking data flow across functions, and CodeQL specifically for the strongest cross-function interprocedural analysis.

Security engineers and code auditors who already have one confirmed bug and need to find every other place the same root cause shows up in a codebase - across the entire repository, not just the module where it was first found, and across every semantically related manifestation of the same logic error, not just the one exact expression.