Rules
xgrep's built-in rule corpus, how to filter it, and how to write your own rules.
Rules
xgrep ships a large built-in rule corpus and runs it by default — no rules file needed. Most users never write a rule; they run the built-ins and filter to the surface they care about.
Built-in rules
The bundled corpus is ~1,000+ security and correctness rules across 12+ languages (Go, Java, JavaScript/TypeScript, Python, Ruby, C#, Swift, Bash, Dockerfile, HCL/Terraform, GitHub Actions, and more), plus 270+ secrets detectors (see Secrets scanning). Rules are grouped into eight categories, and each answers "what is this finding?":
| category | what it reports | how you get it |
|---|---|---|
security | a weakness an attacker could exploit, or a hardening gap that makes one likelier | default scan |
secrets | a credential committed to the source | default scan |
correctness | the program does something other than what its author wrote it to do | --category correctness |
performance | the program is correct but does avoidable work | --category performance |
concurrency | the program is correct on one thread and wrong on several | --category concurrency |
dspm | sensitive data reaching a place that outlives or leaves the process | --dspm |
cbom | a cryptographic asset, inventoried rather than judged | --cbom |
aibom | an AI/ML component, inventoried rather than judged | --aibom |
A second axis says how sure xgrep is that you must act. vuln means
exploitable and attacker-reachable, and only security rules carry it;
audit is everything else a scan reports — hardening, advisory, and every
correctness, performance, concurrency and data-exposure finding; inventory
is not a finding at all. Secrets carry no tier: a committed credential is its own
category, and neither --subcategory nor --exclude-subcategory removes it.
A category name that matches no rule is reported as a warning rather than silently selecting nothing.
# Run the built-ins (security + secrets by default) — no -f needed
xgrep scan .Filtering the built-in rules
Narrow the corpus to what you want to see:
| Flag | What it does |
|---|---|
--category <c,…> | Run only these categories (default security,secrets); e.g. --category correctness. |
--subcategory vuln | Exploitable-only — drop hardening/advisory (audit) rules. High signal. |
--exclude-subcategory audit | The inverse — same effect. Neither form drops secrets, which are untiered. |
--rule-id <id,…> / --skip-rule <id,…> | Include or exclude individual rule IDs. |
--include-opt-in | Also run higher-noise rules marked metadata.opt-in: true (off by default). |
--severity <INFO|WARNING|ERROR> | Minimum severity to report. |
--xgrepignore | Skip non-source trees (tests, benchmarks, examples, vendor). |
# Exploitable-only security scan, focused on source code
xgrep scan --category security --subcategory vuln --xgrepignore .See the CLI reference for the
full rule-selection semantics, and Analysis mode for the
built-in native analyzers (mode: analysis) used by some rules.
Writing your own rules
Need a check the built-ins don't cover? xgrep rules are YAML in the
Semgrep-compatible format, and your rules run alongside the built-in corpus
(-f rules/ --with-builtin security,secrets).
- Writing rules — the rule format and supported features.
- Syntax reference — pattern operators and metavariables.
- Taint analysis — source-to-sink dataflow rules.
- Analysis mode — built-in native analyzers via
mode: analysis. - Testing rules — validate rules against annotated fixtures.