CLI reference

Every command, flag, and default in cxg 1.6.1.

cxg [OPTIONS] [COMMAND]

Commands

Command	Summary
cxg scan	Run templates against network targets or local CLI binaries (cli://<binary>)
cxg build	Build a target with instrumentation so a scan can earn its verdict
cxg template	Manage templates
cxg ai	AI-powered template generation
cxg search	Search templates
cxg server	Run as API server [NOT IMPLEMENTED — returns an error]
cxg config	Generate configuration file
cxg sandbox	Manage per-language dependency environments (does not confine execution)
cxg mcp	MCP (Model Context Protocol) server for AI agent integration
cxg pentest	Whitebox pentests for web/Electron; Tauri source maps and optional in-process proof
cxg update	Update cxg to the latest released build
cxg version	Display version information

Global options

Accepted by every command.

Option	Description
-v, --verbose...	Enable verbose output (-v: info+warn, -vv: +trace, -vvv: +debug)
--no-color	Disable colored output
-c, --config <FILE>	Configuration file path
--ut	Update templates from repository (shorthand for ‘cxg template update’) Aliases: --update-templates.
--auto-update-templates	Automatically update templates before running scan
--disable-update-check	Disable automatic template update check on startup
--update-templates-on-startup	Force template update on every startup (aggressive)
-h, --help	Print help (see a summary with ‘-h’)
-V, --version	Print version

Full trailing help from cxg --help

KEY FEATURES:
  🎯 12 Programming Languages: Python, JavaScript, Rust, C, C++, Java, Go, Ruby, Perl, PHP, Shell, YAML
  🔧 Flexible Port Configuration: Add or override ports per scan
  🔍 Powerful Template Search: Full-text search, regex, content search, multiple filters
  ⚡ High Performance: Parallel execution, compilation caching for compiled languages
  📊 Multiple Output Formats: JSON, CSV, SARIF, HTML, Markdown
  🔌 Extensible: Custom templates in any supported language

EXAMPLES:
  # Local CLI binary (CLI Security Baseline from the detection-template repository)
  cxg template update
  cxg scan --scope cli:///absolute/path/to/my-tool --template-dir ~/.cert-x-gen/templates/official/templates/cli-baseline --require-instrumentation

  # Tauri source map, then optional in-process command proof (no live webview)
  cxg pentest install
  cxg pentest run --target-type tauri --codebase ./app-repo
  cxg pentest run --target-type tauri --codebase ./app-repo --tauri-prove

  # Basic scanning
  cxg scan --scope example.com
  cxg scan --scope https://api.example.com:8443 --ports 80,443,8080
  cxg scan --scope 192.168.1.0/24 --top-ports 1000

  # Bulk input
  cxg scan --scope @targets.txt
  cxg scan --scope file://scopes/internal.txt

  # Advanced scanning with filters
  cxg scan --scope example.com --template-language python,rust
  cxg scan --scope example.com --severity critical,high
  cxg scan --scope example.com --tags database,unauthenticated

  # Template search
  cxg search --query "redis"
  cxg search --language python --severity high
  cxg search --query "injection" --content --regex
  cxg search --tags "database,unauthenticated" --format json

  # Template management
  cxg template list
  cxg template list --language c --severity critical
  cxg template info redis-unauthenticated

  # Template search
  cxg search --query "redis"
  cxg search --language python --severity high
  cxg search --tags "injection,sql" --format json

  # Configuration
  cxg config generate --output config.yaml
  cxg scan --config config.yaml --scope example.com

  # Output formats
  cxg scan --scope example.com --output-format json,csv,sarif
  cxg scan --scope example.com --output results --output-format json

  # Performance tuning
  cxg scan --scope example.com --parallel-targets 100 --parallel-templates 20
  cxg scan --scope example.com --timeout 60s --retry 5

  # Stealth and safety
  cxg scan --scope example.com --stealth --rate-limit 10
  cxg scan --scope example.com --safe --passive

  For detailed help on any command, use: cxg <command> --help

LINKS:
  Repository:    https://github.com/Bugb-Technologies/cert-x-gen
  Documentation: https://docs.bugb.io/cxg/
  Issues:        https://github.com/Bugb-Technologies/cert-x-gen/issues

cxg scan

Run templates against network targets or local CLI binaries (cli://<binary>)

cxg scan [OPTIONS]

Target Selection

Option	Description
-s, --scope <SCOPE>	Smart target selector. Accepts single host, comma lists, files (@file.txt), CIDR blocks (192.168.1.0/24), domains, URLs, or local CLI binaries (cli:///absolute/path/to/my-tool). CLI scopes select a local process, not a network host; ports have no meaning for CLI targets. Binary paths preserve commas. Legacy flags (--target, --targets, --target-file, --domain, --domains, --domain-file, --cidr) remain as aliases.
-p, --ports <PORT>	Smart port selector. Accepts single ports, ranges (80-90), comma lists, files (@ports.txt), or mixed entries. These are ADDED to each template’s default ports; use --override-ports to replace them instead.
--top-ports <TOP_PORTS>	Add the top N most common ports (based on curated frequency data). Example: --top-ports 1000
--override-ports <OVERRIDE_PORTS>	Replace template default ports entirely with your own list (same formats as --ports). Use for complete control over port selection.

Template Selection

Option	Description
--templates <TEMPLATE>	Smart template selector. Accepts template IDs, file names/paths, or @file references (one per line). Supports mixed entries. Legacy flags (--template, --template-file) remain as aliases.
--template-language <LANG>	Filter templates by programming language. Available: yaml, python, rust, shell, javascript, c, cpp, java, go, ruby, perl, php. Values below.
--severity <SEVERITY>	Filter templates by severity level. Example: --severity critical,high for a quick, high-signal assessment. Values below.
--tags <TAGS>	Filter templates by tags (comma-separated). Common tags: database, injection, xss, rce, lfi, ssrf, auth.
--exclude-templates <EXCLUDE_TEMPLATES>	Exclude templates matching a pattern. Supports wildcards. Example: --exclude-templates test-,experimental-
--template-dir <TEMPLATE_DIR>	Use templates from a custom directory instead of the default discovery locations.
--context <JSON>	JSON context passed to templates via the CERT_X_GEN_CONTEXT environment variable. Templates read this to receive parameterized input (target URLs, parameter names, HTTP methods, baselines, etc.) without hardcoding values. Example: ‘{“param_name”:“username”,“method”:“POST”}’
--batch-group <GROUP>	Run only templates belonging to this batch group. Batch groups let you execute a cohort of templates that share the same context shape in a single invocation. Common groups: auth-context, endpoint-params, service-ports, full-surface.

--template-language values

Value	Meaning
yaml	YAML declarative templates
python	Python interpreted templates
rust	Rust compiled templates
shell	Shell/Bash script templates
java-script	JavaScript/Node.js templates
c	C compiled templates
cpp	C++ compiled templates
java	Java compiled templates
go	Go compiled templates
ruby	Ruby interpreted templates
perl	Perl interpreted templates
php	PHP interpreted templates

--severity values

Value	Meaning
critical	Critical severity (highest priority)
high	High severity
medium	Medium severity
low	Low severity
info	Informational (lowest priority)

Probe Input

Option	Description
--arg <ARG>	Argument passed through to the target the template drives, not to the template itself. Repeat for an argument vector; hyphen-leading values are accepted, so the target’s own flags can be passed. Delivered to the template as CERT_X_GEN_ARGV (a JSON array). Example: --arg --label --arg AAAAAAAAAAAAAAAAAAAA
--stdin-file <PATH>	Path to a file whose bytes the template should feed to the target’s stdin. Delivered as CERT_X_GEN_STDIN_FILE, canonicalised, so the template does not depend on its working directory.
--input <DIR>	Directory of seed inputs the template may iterate over. Delivered as CERT_X_GEN_INPUT_DIR. cxg does not mutate or minimise the corpus – corpus search is discovery, and cxg verifies – it only hands over the directory.
--target-env <K=V>	Environment variable the template should set on the target process, not on itself. Delivered as CERT_X_GEN_TARGET_ENV (a JSON object). Repeatable; a repeated key takes its last value. Typical use is sanitizer runtime control, e.g. --target-env ASAN_OPTIONS=abort_on_error=1
--require-instrumentation	Instrumentation preflight. For each cli:// target, inspect the binary for sanitizer, coverage and debug-info markers before running anything against it. If none are present, record as SKIPPED with the reason no-instrumentation-detected every (template, target) execution whose oracles needed that instrumentation, instead of running the probe and reporting a ‘no findings’ result that looks like a refutation but is not evidence. A template declaring only oracles that work on any build (exit, signal, timeout, exception, property) still runs and reaches a real verdict. The build cxg wants is the language’s instrumented one, e.g. clang -fsanitize=address -g; cxg inspects and refuses, it does not build the target – see cxg build --instrument for the verb that does.
--instrumented-manifest <PATH>	Manifest written by cxg build --instrument, naming a binary and the instrumentation cxg verified in it at build time. Provenance beats inspection: cxg passed the flags and read the produced artefact back before it was willing to call the build instrumented, and that record survives stripping and a copy away from the build tree. The record applies only to the binary the manifest names; every other target is inspected exactly as before. Repeatable. Omit it and the scan behaves identically to one run before this flag existed.

Execution

Option	Description
--parallel-targets <PARALLEL_TARGETS>	How many targets to scan simultaneously. Lower for production systems (10-25), higher for internal scans (50-100). Default: 50.
--parallel-templates <PARALLEL_TEMPLATES>	How many templates to run concurrently per target. Balances speed against load on the target. Lower for fragile targets, higher for robust ones. Default: 10.
--timeout <TIMEOUT>	Maximum time to wait for a response. Supports s (seconds), m (minutes), h (hours). Increase for slow networks or complex checks. Default: 30s.
--retry <RETRY>	Number of retry attempts for failed requests. Higher for unreliable networks, lower for fast scans. Default: 1.
--rate-limit <RATE_LIMIT>	Maximum requests per second. Use 10-50 for production, 100+ for internal testing. Prevents overwhelming targets and triggering WAF/IPS.
--aggressive	Aggressive scanning with intrusive checks and higher concurrency. WARNING: may trigger security alerts or cause disruption. Use only with explicit permission on systems you control.
--stealth	Stealth mode: randomized timing and reduced footprint to evade IDS/IPS/WAF detection. Slower, but less likely to be flagged.
--passive	Passive scanning: analyze responses from normal requests only, with no active probing. Safest option, but limited detection capability.
--safe	Safe mode: excludes potentially harmful checks (DoS, resource exhaustion). Recommended for production systems where availability is critical.

Network

Option	Description
--proxy <PROXY>	Route all traffic through a proxy. Supports HTTP, HTTPS, and SOCKS5. Examples: http://proxy:8080, socks5://127.0.0.1:1080
--user-agent <USER_AGENT>	Custom User-Agent header, for mimicking specific browsers or tools. Default: cert-x-gen/<version>. Example: “Mozilla/5.0 …”
--header <HEADER>	Add a custom HTTP header. Repeatable for multiple headers. Useful for authentication, API keys, or custom application headers. Example: --header “Authorization: Bearer token”
--cookie <COOKIE>	Add a cookie to requests. Repeatable. Useful for authenticated scans. Example: --cookie “session=abc123”
--follow-redirects	Follow HTTP redirects automatically, for discovering redirect chains and final destinations. Default: Disabled — redirects are not followed unless this flag is passed.
--max-redirects <MAX_REDIRECTS>	Maximum number of redirects to follow (when --follow-redirects is set). Prevents infinite redirect loops. Default: 5.

Output

Option	Description
-o, --output <OUTPUT>	Output file basename. The trailing extension (if any) is REPLACED by the chosen format’s extension — e.g. --output report.txt --output-format json writes report.json. Default: scan-results.
--output-format <OUTPUT_FORMAT>	Output formats (comma-separated); several can be generated at once. Available: json (automation), csv (spreadsheet), sarif (CI/CD), html (visual report), markdown (docs). Default: json.
-q, --quiet	Suppress the ASCII startup banner. Scan output itself is unchanged.

Accepted and ignored

cxg accepts every flag below and ignores it. Passing one does not fail, warn, or change the scan. The markers are reproduced from --help.

Option	Description
--protocol <PROTOCOL>	Specify protocol: http, https, tcp, udp, etc. [NOT IMPLEMENTED — accepted and ignored]
--protocols <PROTOCOLS>	Test multiple protocols (comma-separated). Example: http,https [NOT IMPLEMENTED — accepted and ignored]
--threads <THREADS>	Worker threads for parallel execution. Concurrency is actually controlled by --parallel-targets and --parallel-templates. [NOT IMPLEMENTED — accepted and ignored] Default: 2.
--stream	Stream results in real-time as they are found. [NOT IMPLEMENTED — accepted and ignored]
--resume <RESUME>	Resume a scan from where it stopped. [NOT IMPLEMENTED — accepted and ignored]
--distributed	Distributed mode: coordinate with other scanners for massive scans. [NOT IMPLEMENTED — accepted and ignored]
--coordinator <COORDINATOR>	Coordinator URL for distributed mode. [NOT IMPLEMENTED — accepted and ignored]
--worker-id <WORKER_ID>	Worker identifier in distributed mode. [NOT IMPLEMENTED — accepted and ignored]
--profile <PROFILE>	Use a named profile from the config file. [NOT IMPLEMENTED — accepted and ignored]

The global options apply here too.

Full trailing help from cxg scan --help

LOCAL CLI TESTING:
  Use cli://<binary> with an absolute executable path (cli:///absolute/path/to/my-tool).
  Fetch the CLI Security Baseline pack from the detection-template repository:
  https://github.com/Bugb-Technologies/cert-x-gen-templates/tree/main/templates/cli-baseline
  With the default repository configuration:
    cxg template update
    cxg scan --scope cli:///absolute/path/to/my-tool --template-dir ~/.cert-x-gen/templates/official/templates/cli-baseline --require-instrumentation
  This repository's templates/ contains skeletons, not the detection pack.
  A skipped check provides no refutation; no findings alone does not establish safety.

  Optional probe inputs (the selected template must consume this contract):
    cxg scan --scope cli:///absolute/path/to/my-tool --templates /path/to/probe.sh --arg --format --arg json --stdin-file ./case.bin --input ./corpus --target-env ASAN_OPTIONS=abort_on_error=1 --require-instrumentation
  cxg passes argv, stdin file, seed corpus and target environment to templates; it does
  not automatically adapt every template to the target's syntax or mutate the corpus.
  Templates declare @oracles and report confirmed/refuted/skipped/errored/timed-out.
  A nonzero exit alone does not prove an unhandled exception.
  --require-instrumentation checks binary markers and oracle requirements; unsupported
  executions skip (no-instrumentation-detected, oracle-unavailable(...), target-not-found).
  Build-independent oracles (exit, signal, timeout, exception, property) can run with none.
  Interpreted scripts detect none; target-kind declarations apply even without preflight.
  Scanning does not build the target: see cxg build --help for instrumented build options,
  then use --instrumented-manifest <PATH> for provenance of the binary it names.
  Tauri IPC testing uses cxg pentest run --target-type tauri --codebase <repo>.

DETAILED USAGE GUIDE:

TARGET SPECIFICATION:
  Define scope once and let the engine figure out the rest.

  --scope <SCOPE>
    Smart selector that accepts:
      • Single host or URL (example.com, https://api.example.com:8443)
      • Comma-separated lists (example.com,test.com,192.168.1.1)
      • Files via @targets.txt or file://path/to/targets.txt (one entry per line, # for comments)
      • CIDR ranges (192.168.1.0/24, 10.0.0.0/8)
      • Domains and subdomains (example.com, api.example.com)
      • Mixed entries in a single invocation

    Legacy flags (--target, --targets, --target-file, --domain, --domains, --domain-file, --cidr) remain as aliases.
    The scanner automatically deduplicates and expands entries from files.

PORT SELECTION:
  Customize which ports to scan.

  --ports <PORT>
    Smart selector that adds ports to template defaults. Supports:
      • Single ports (8080)
      • Ranges (8000-8100)
      • Comma lists (80,443,8443)
      • Files via @ports.txt or file://ports.txt (one per line, # for comments)
      • Mixed entries in a single invocation
    Adds to template default ports; combine with --override-ports to replace defaults entirely.
    Example:
      cxg scan --scope example.com --ports 80,443,8000-8010,@extra-ports.txt

  --top-ports <N>
    Add the top N most common ports (based on curated frequency data).
    Example:
      cxg scan --scope example.com --top-ports 100

  --override-ports <PORTS>
    Replace template default ports entirely with your custom list (same formats as --ports).
    Example:
      cxg scan --scope example.com --override-ports 80,443

TEMPLATE FILTERING:
  Control which vulnerability templates are executed. Filter by ID, language, severity, or tags.

  --templates <TEMPLATE>
    Smart selector that understands template IDs, filenames, or file paths. Supports:
      • Direct template IDs (redis-unauthenticated)
      • File names or paths (templates/network/redis.yaml)
      • Files containing template lists via @templates.txt or file://templates.txt (one per line, # for comments)
      • Mixed entries in a single invocation
    Legacy flags (--template, --template-file) remain as aliases.
    Examples:
      cxg scan --scope example.com --templates redis-unauthenticated
      cxg scan --scope example.com --templates redis-unauthenticated,templates/network/redis.yaml
      cxg scan --scope example.com --templates @compliance-templates.txt

  --template-dir <DIR>
    Use templates from a custom directory instead of the default location.
    Example:
      cxg scan --scope example.com --template-dir ./custom-templates

  --template-language <LANGUAGES>
    Filter templates by programming language. Useful for testing specific engine types.
    Available: yaml, python, rust, shell, javascript, c, cpp, java, go, ruby, perl, php
    Example:
      cxg scan --scope example.com --template-language python --template-language rust

  --severity <SEVERITIES>
    Filter by severity level. Run only critical/high severity checks for quick assessments.
    Available: critical, high, medium, low, info
    Example:
      cxg scan --scope example.com --severity critical,high

  --tags <TAGS>
    Filter templates by tags (comma-separated). Tags categorize vulnerabilities.
    Common tags: database, injection, xss, authentication, authorization, rce, lfi, ssrf
    Example:
      cxg scan --scope example.com --tags database,unauthenticated

  --exclude-templates <PATTERN>
    Exclude templates matching a pattern. Supports wildcards.
    Example:
      cxg scan --scope example.com --exclude-templates test-*,experimental-*

OUTPUT AND REPORTING:
  Customize how scan results are saved and displayed.

  --output <BASENAME>
    Set the output file basename. Any trailing extension is REPLACED by the chosen
    format's extension — e.g. `--output report.txt --output-format json` writes report.json.
    Default: scan-results
    Example:
      cxg scan --scope example.com --output my-scan --output-format json
      # Writes: my-scan.json

  --output-format <FORMATS>
    Specify output formats (comma-separated). Multiple formats can be generated simultaneously.
    Available: json, csv, sarif, html, markdown
    - json: Machine-readable, ideal for automation and APIs
    - csv: Spreadsheet-friendly, good for reporting and analysis
    - sarif: Static Analysis Results Interchange Format (for CI/CD integration)
    - html: Human-readable report with visualizations
    - markdown: Human-readable Markdown report
    Example:
      cxg scan --scope example.com --output-format json,html,sarif

  --quiet
    Suppress the ASCII startup banner. Scan output itself is unchanged.
    Example:
      cxg scan --scope example.com --quiet

PERFORMANCE AND CONCURRENCY:
  Tune scan performance based on your resources and target infrastructure.

  --parallel-targets <N>
    How many targets to scan simultaneously. Higher = faster but may trigger rate limits.
    Default: 50
    Recommendation: Lower for production systems (10-25), higher for internal scans (50-100)
    Example:
      cxg scan --scope example.com,test.com --parallel-targets 10

  --parallel-templates <N>
    How many templates to run concurrently per target. Balances speed vs. target load.
    Default: 10
    Recommendation: Lower for fragile targets (5), higher for robust systems (20)
    Example:
      cxg scan --scope example.com --parallel-templates 5

TIMEOUTS AND RETRIES:
  Configure how the scanner handles slow responses and failures.

  --timeout <DURATION>
    Maximum time to wait for a response. Supports: s (seconds), m (minutes), h (hours)
    Default: 30s
    Recommendation: Increase for slow networks or complex checks
    Example:
      cxg scan --scope example.com --timeout 60s
      cxg scan --scope example.com --timeout 2m

  --retry <N>
    Number of retry attempts for failed requests. Helps with transient network issues.
    Default: 1
    Recommendation: Increase for unreliable networks, decrease for fast scans
    Example:
      cxg scan --scope example.com --retry 5

  --rate-limit <N>
    Maximum requests per second. Prevents overwhelming targets and triggering WAF/IPS.
    Default: None (unlimited)
    Recommendation: Use 10-50 for production, 100+ for internal testing
    Example:
      cxg scan --scope example.com --rate-limit 10

SCANNING MODES:
  Different modes for various scanning scenarios and requirements.

  --aggressive
    Enable aggressive scanning mode. Uses more intrusive checks and higher concurrency.
    WARNING: May trigger security alerts or cause service disruption.
    Use only with explicit permission on systems you control.
    Example:
      cxg scan --scope test-env.internal --aggressive

  --stealth
    Enable stealth mode. Reduces scan footprint, randomizes timing, and mimics normal traffic.
    Slower but less likely to trigger detection systems (IDS/IPS/WAF).
    Automatically reduces concurrency and adds random delays.
    Example:
      cxg scan --scope example.com --stealth

  --safe
    Safe mode - excludes potentially harmful checks (DoS, resource exhaustion, etc.).
    Recommended for production systems where availability is critical.
    Example:
      cxg scan --scope production.example.com --safe

  --passive
    Passive mode - no active probing. Only analyzes responses from normal requests.
    Safest option but limited detection capabilities. Good for initial reconnaissance.
    Example:
      cxg scan --scope example.com --passive

NETWORK CONFIGURATION:
  Configure network-level settings for scanning through proxies, with custom headers, etc.

  --proxy <URL>
    Route all traffic through a proxy. Supports HTTP, HTTPS, and SOCKS5 proxies.
    Useful for scanning from different geographic locations or through corporate proxies.
    Examples:
      cxg scan --scope example.com --proxy http://proxy.corp.com:8080
      cxg scan --scope example.com --proxy socks5://127.0.0.1:1080

  --user-agent <STRING>
    Custom User-Agent header. Useful for mimicking specific browsers or tools.
    Default: cert-x-gen/<version>
    Example:
      cxg scan --scope example.com --user-agent 'Mozilla/5.0 (Windows NT 10.0; Win64; x64)'

  --header <KEY:VALUE>
    Add custom HTTP headers. Can be specified multiple times for multiple headers.
    Useful for authentication, API keys, or custom application headers.
    Examples:
      cxg scan --scope api.example.com --header 'Authorization: Bearer token123'
      cxg scan --scope example.com --header 'X-API-Key: abc' --header 'X-Custom: value'

  --cookie <KEY=VALUE>
    Add cookies to requests. Can be specified multiple times. Useful for authenticated scans.
    Example:
      cxg scan --scope example.com --cookie 'session=abc123' --cookie 'user=admin'

  --follow-redirects
    Follow HTTP redirects automatically. Useful for discovering redirect chains.
    Default: Disabled (redirects are not followed unless this flag is passed)
    Example:
      cxg scan --scope example.com --follow-redirects --max-redirects 10

  --max-redirects <N>
    Maximum number of redirects to follow. Prevents infinite redirect loops.
    Default: 5
    Example:
      cxg scan --scope example.com --max-redirects 3

CONFIGURATION FILES:
  Use configuration files for complex setups.

  --config <FILE>
    Load settings from a configuration file (YAML, TOML, or JSON).
    CLI arguments override config file settings.
    Example:
      cxg scan --config production-scan.yaml --scope example.com

COMMON SCANNING SCENARIOS:

1. Quick Vulnerability Assessment (Fast, High-Severity Only):
   cxg scan --scope example.com --severity critical,high

2. Comprehensive Security Audit (All Templates, All Severities):
   cxg scan --scope example.com --output-format json,html,sarif

3. Stealth Penetration Test (Low Detection Risk):
   cxg scan --scope example.com --stealth --rate-limit 5 --timeout 60s

4. Production System Scan (Safe, Non-Disruptive):
   cxg scan --scope production.example.com --safe --parallel-templates 3 --rate-limit 10

5. Database Security Scan (Specific Vulnerability Class):
   cxg scan --scope db.example.com --tags database,injection --severity high,critical

6. Authenticated Web Application Scan:
   cxg scan --scope app.example.com --cookie 'session=xyz' --header 'Authorization: Bearer token'

7. Large-Scale Network Scan (Multiple Targets):
   cxg scan --scope @targets.txt --parallel-targets 100 --output-format csv,json

8. API Security Testing:
   cxg scan --scope api.example.com --template-language python --tags api,authentication

9. Compliance Scan (OWASP Top 10):
   cxg scan --scope example.com --templates @owasp-top10.txt --output-format sarif

10. Internal Network Reconnaissance:
    cxg scan --scope 10.0.0.0/24 --passive --top-ports 100 --quiet

For more information, visit: https://cert-x-gen.io/docs

cxg build

Build a target with instrumentation so a scan can earn its verdict

cxg scan inspects a binary and refuses; it never builds the target. This is the deliberate opt-in on the other side of that line, and it is a separate verb rather than a scan flag for three reasons: building runs the project’s own build system (build.rs, configure, arbitrary Makefile recipes) as you, which is a different trust decision from reading a file; it costs minutes and gigabytes, which is a bad surprise as a side effect and a fine one as a decision; and one instrumented build feeds many scans.

It prints one JSON manifest and nothing else. There is no path from “I could not instrument this” to “here is a binary”: every precondition failure is a skipped with a machine-readable reason, and the last check re-reads the binary that was just produced, so a build that accepted the flags and silently dropped them skips rather than passes.

cxg build [OPTIONS]

Option	Description
--instrument	Build the target with sanitizer instrumentation. Required: cxg build has no other mode, and demanding the word keeps room for one without changing what this invocation means.
--project <DIR>	Directory holding the project to build. The build system is detected from its marker files in priority order (Cargo.toml, CMakeLists.txt, go.mod, configure, Makefile, meson.build); Cargo.toml first, so a polyglot repository such as a Tauri app instruments its Rust binary. A tree matching none of them skips with unknown-build-system rather than being guessed at. Default: ..
--bin <NAME>	Which binary target to build. Inferred when the project has exactly one; a workspace with several skips with binary-target-ambiguous rather than instrumenting one nobody asked for.
--sanitizer <LIST>	Comma-separated sanitizers, in rustc’s vocabulary: address, thread, memory. Capability is asked of rustc per target rather than guessed, so a request the target cannot serve (MSan on arm64 macOS) skips with sanitizer-unsupported-on-target. Note that Rust has NO UBSan – -Zsanitizer=undefined does not exist on any target – so undefined skips with a note naming the Rust equivalent for the integer class, -C overflow-checks=on, which cxg passes on every instrumented build anyway. Default: address.
--out <DIR>	Where to put the instrumented build tree; defaults to <project>/target-instrumented. Never the project’s own target/: RUSTFLAGS is part of cargo’s fingerprint, so sharing one forces a full rebuild in both directions every time you alternate between an instrumented scan and ordinary work. Budget several gigabytes per instrumented project.
--build-std	Rebuild std with the sanitizer. Needs the rust-src component. Mandatory for MSan, whose uninstrumented std reports uninitialised reads everywhere, and merely better for ASan, which interposes the allocator and so catches heap errors through a precompiled std. Off by default.
--manifest <PATH>	Write the manifest to this file as well as to stdout. Hand it back to a scan with cxg scan --instrumented-manifest <path> so the scan trusts what cxg recorded at build time instead of re-inspecting the artefact.
-q, --quiet	Print only the path of the instrumented binary, and nothing at all on a skip, for cxg scan --scope cli://$(cxg build --instrument --project . -q). The exit status still distinguishes the two: 0 instrumented, 3 skipped.

The global options apply here too.

cxg search

Search templates

After cxg template update, use cxg template search baseline --tags cli to discover CLI Security Baseline templates from cert-x-gen-templates.

cxg search [OPTIONS]

Option	Description
-q, --query <TEXT>	Search query (searches in name, description, tags, and optionally content)
--language <LANG>	Filter by programming language Values below.
--severity <LEVEL>	Filter by severity level Values below.
--tags <TAG,TAG,...>	Filter by tags (comma-separated); use cli for local CLI templates
--author <NAME>	Filter by template author
--cwe <CWE-ID>	Filter by CWE ID (e.g., CWE-89)
--content	Search in template content/code (slower but more comprehensive)
--case-sensitive	Use case-sensitive search
--regex	Treat query as regex pattern
--limit <N>	Maximum number of results to return Default: 50.
--format <FORMAT>	Output format for search results Default: table. Values below.
-o, --output <FILE>	Output file for results (default: print to stdout)
--detailed	Show detailed information for each result
--sort <FIELD>	Sort results by field Default: relevance. Values below.
--reverse	Reverse sort order
--ids-only	Show only template IDs (useful for piping to other commands)
--stats	Show search statistics and summary

--language values

Value	Meaning
yaml	YAML declarative templates
python	Python interpreted templates
rust	Rust compiled templates
shell	Shell/Bash script templates
java-script	JavaScript/Node.js templates
c	C compiled templates
cpp	C++ compiled templates
java	Java compiled templates
go	Go compiled templates
ruby	Ruby interpreted templates
perl	Perl interpreted templates
php	PHP interpreted templates

--severity values

Value	Meaning
critical	Critical severity (highest priority)
high	High severity
medium	Medium severity
low	Low severity
info	Informational (lowest priority)

--format values

Value	Meaning
table	Table format (human-readable, default)
json	JSON format (machine-readable)
yaml	YAML format
csv	CSV format (spreadsheet-compatible)
list	Simple list format (template IDs only)
detailed	Detailed format (all information)

--sort values

Value	Meaning
relevance	Sort by relevance score (default)
name	Sort by template name
language	Sort by programming language
severity	Sort by severity level
author	Sort by author name
date	Sort by creation/update date
popularity	Sort by popularity/usage

The global options apply here too.

Full trailing help from cxg search --help

SEARCH CAPABILITIES:
  • Full-text search in names, descriptions, and tags
  • Regex pattern matching
  • Content search (searches inside template code)
  • Multiple filters (language, severity, tags, author, CWE)
  • Multiple output formats (table, json, yaml, csv, list, detailed)
  • Sorting and pagination

EXAMPLES:
  # Discover installed CLI Security Baseline templates
  cxg template update
  cxg search --tags cli

  # Basic text search
  cxg search --query "redis"
  cxg search --query "sql injection"
  cxg search --query "unauthenticated access"

  # Language-specific search
  cxg search --language python
  cxg search --language c --query "buffer overflow"
  cxg search --language rust --severity critical

  # Severity filtering
  cxg search --severity critical
  cxg search --severity high --language python
  cxg search --severity critical,high

  # Tag-based search
  cxg search --tags database
  cxg search --tags "database,unauthenticated"
  cxg search --tags injection --language c

  # Author and CWE filtering
  cxg search --author "CERT-X-GEN"
  cxg search --cwe "CWE-89"
  cxg search --cwe "CWE-306" --severity critical

  # Advanced search with regex
  cxg search --query "redis|mysql|postgres" --regex
  cxg search --query "SQL.*injection" --regex --case-sensitive

  # Content search (slower but comprehensive)
  cxg search --query "curl" --content
  cxg search --query "SELECT.*FROM" --content --regex

  # Output formats
  cxg search --query "redis" --format table        # Default
  cxg search --query "redis" --format json
  cxg search --query "redis" --format csv
  cxg search --query "redis" --format yaml
  cxg search --query "redis" --format detailed

  # Sorting and limiting
  cxg search --query "injection" --sort name
  cxg search --query "injection" --sort severity --reverse
  cxg search --query "injection" --limit 10

  # Get only template IDs (useful for piping to scan)
  cxg search --query "redis" --ids-only
  TEMPLATES=$(cxg search --query "redis" --ids-only | tr '\n' ',')
  cxg scan --target example.com --templates "$TEMPLATES"

  # Show statistics
  cxg search --query "redis" --stats
  cxg search --language python --stats

  # Save results to file
  cxg search --query "redis" --output results.json --format json
  cxg search --language c --output c-templates.csv --format csv

  # Complex queries
  cxg search --language python --severity high --tags database --format json
  cxg search --query "authentication" --content --case-sensitive --regex
  cxg search --author "CERT-X-GEN" --severity critical --sort date --reverse

cxg config

Generate configuration file

cxg config [OPTIONS] <COMMAND>

Subcommand	Summary
generate	Generate a default configuration file
validate	Validate a configuration file
show	Show current/default configuration

The global options apply here too.

Full trailing help from cxg config --help

EXAMPLES:
  # Generate default configuration
  cxg config generate
  cxg config generate --output config.yaml
  cxg config generate --format toml --output config.toml

  # Validate configuration
  cxg config validate config.yaml
  cxg config validate production.toml

  # Show current/default configuration
  cxg config show

cxg config generate

Generate a default configuration file

cxg config generate [OPTIONS]

Option	Description
-o, --output <FILE>	Output file path Default: cert-x-gen.yaml.
-f, --format <FORMAT>	Configuration format Default: yaml. Values below.

--format values

Value	Meaning
yaml	YAML format
toml	TOML format
json	JSON format

The global options apply here too.

cxg config validate

Validate a configuration file

cxg config validate [OPTIONS] <CONFIG>

Arguments

Option	Description
<CONFIG>	Configuration file to validate

The global options apply here too.

cxg config show

Show current/default configuration

cxg config show [OPTIONS]

The global options apply here too.

cxg mcp

MCP (Model Context Protocol) server for AI agent integration

cxg mcp [OPTIONS] [COMMAND]

Subcommand	Summary
install	Configure MCP server for AI coding agents (Claude Desktop, Claude Code, Cursor, etc.)
uninstall	Remove MCP server configuration from AI coding agents
status	Show current MCP configuration status across all detected clients

The global options apply here too.

cxg mcp install

Configure MCP server for AI coding agents (Claude Desktop, Claude Code, Cursor, etc.)

cxg mcp install [OPTIONS]

Option	Description
--client <CLIENT>	Specific clients to configure (comma-separated: claude-desktop,claude-code,cursor,windsurf,vscode,zed)

The global options apply here too.

cxg mcp uninstall

Remove MCP server configuration from AI coding agents

cxg mcp uninstall [OPTIONS]

Option	Description
--client <CLIENT>	Specific clients to unconfigure

The global options apply here too.

cxg mcp status

Show current MCP configuration status across all detected clients

cxg mcp status [OPTIONS]

The global options apply here too.

cxg server

Run as API server [NOT IMPLEMENTED — returns an error]

cxg server [OPTIONS]

Option	Description
-p, --port <PORT>	Server port Default: 8080.
-b, --bind <ADDRESS>	Bind address (use 0.0.0.0 to listen on all interfaces) Default: 127.0.0.1.
--auth-token <TOKEN>	Authentication token for API requests
--tls	Enable TLS/HTTPS
--tls-cert <FILE>	TLS certificate file path
--tls-key <FILE>	TLS private key file path

The global options apply here too.

cxg update

Update cxg to the latest released build

cxg update [OPTIONS]

Option	Description
--check	Only check whether a newer version exists; don’t download or install
--version <VERSION>	Install a specific release tag (e.g. v1.2.0) instead of the latest
-y, --yes	Skip the confirmation prompt before replacing the binary
--force	Replace the binary even when a package manager owns it. Without this, a cxg installed by Homebrew, by cargo install or inside a container is left alone: cxg update prints the command that upgrades it through its manager and exits with status 3, because replacing the file behind the manager’s back leaves the manager believing the old version is installed.

The global options apply here too.

cxg version

Display version information

cxg version [OPTIONS]

The global options apply here too.