Rules

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 categories — security, secrets, correctness, performance, concurrency, resource-management — and every security rule carries an exploitability tier (vuln / audit).

# 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:

FlagWhat it does
--category <c,…>Run only these categories (default security,secrets); e.g. --category correctness.
--subcategory vulnExploitable-only — drop hardening/advisory (audit) rules. High signal.
--exclude-subcategory auditThe inverse — same effect when every rule is tiered.
--rule-id <id,…> / --skip-rule <id,…>Include or exclude individual rule IDs.
--include-opt-inAlso run higher-noise rules marked metadata.opt-in: true (off by default).
--severity <INFO|WARNING|ERROR>Minimum severity to report.
--xgrepignoreSkip 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).

On this page