Security Testing Tools in Strix: 9 Built-In Scanners and When to Use Each

Strix integrates nine specialized security testing tools—including Subfinder, Naabu, Nmap, SQLMap, Semgrep, Nuclei, Katana, httpx, and ffuf—into a unified agent-driven framework that executes commands via strix/tools/executor.py and registers them through strix/tools/registry.py.

The open-source usestrix/strix repository provides a modular platform for autonomous security assessments. Each security testing tool is defined as a Markdown playbook under strix/skills/tooling/ and dynamically loaded at runtime, allowing agents to chain reconnaissance, enumeration, and exploitation tasks without hard-coded dependencies.

How Strix Orchestrates Security Testing Tools

Strix does not simply wrap third-party binaries; it abstracts them into tooling skills that agents discover based on scan mode (quick, standard, or deep).

The Tool Registry

The strix/tools/registry.py module maintains a central map of available capabilities. When an agent initializes, the registry loads skill definitions from the Markdown playbooks in strix/skills/tooling/ and exposes them as callable actions.

Command Execution and Sandboxing

Actual invocation flows through strix/tools/executor.py, which runs the CLI commands defined in each playbook inside sandboxed Docker containers. The strix/tools/terminal/terminal_actions_schema.xml file defines the terminal_execute interface that agents use to trigger these commands.

Structured Output Processing

Every tool is configured to output JSON or JSONL (via flags like -oJ, -j, or --json). This standardized format allows strix/tools/reporting/reporting_actions.py to ingest findings directly, perform deduplication, and enrich CVE data without custom parsing logic.

Phase 1: Reconnaissance and Network Enumeration

Subfinder — Passive Subdomain Enumeration

When to use: Run Subfinder at the very beginning of an assessment to build a complete inventory of subdomains without sending traffic to the target.

This tool performs passive enumeration using certificate transparency logs and search engines. According to the playbook in strix/skills/tooling/subfinder.md, agents invoke it to generate a seed list for subsequent scanning.

subfinder -d example.com -all -recursive -rl 20 -timeout 30 -silent -oJ -o subfinder.jsonl

Naabu — Fast Port Scanning

When to use: Deploy Naabu immediately after identifying live hosts to quickly narrow down which ports are open before launching heavier scans.

Naabu excels at high-speed TCP SYN or connect scans. The naabu.md playbook specifies flags for rate limiting and JSONL output so the registry can pipe results directly into Nmap or Nuclei workflows.

naabu -list hosts.txt -top-ports 100 -scan-type c -Pn -rate 300 -c 25 -timeout 1000 -retries 1 -verify -silent -j -o naabu.jsonl

Nmap — Service Discovery and Version Detection

When to use: Execute Nmap after Naabu has bounded the attack surface to perform deep service fingerprinting and NSE script execution.

The nmap.md playbook configures a two-pass approach: a quick discovery scan followed by an enrichment pass. This prevents wasting time on closed ports while still capturing banner data and version strings.

nmap -n -Pn --open --top-ports 100 -T4 --max-retries 1 --host-timeout 90s -oA nmap_quick <target>

Phase 2: Web Application Mapping

Katana — Web Crawling

When to use: Run Katana once you have confirmed web services (via Nmap or httpx) to map the full attack surface including JavaScript-rendered endpoints and hidden parameters.

Defined in strix/skills/tooling/katana.md, this tool builds a structured map of the application for downstream fuzzing.

katana -u https://app.example.com -d 2 -depth 3 -timeout 20 -silent -output katana.jsonl

httpx — HTTP Probing and Banner Grabbing

When to use: Use httpx to validate that URLs discovered during subdomain enumeration or crawling are actually reachable, and to collect metadata like status codes, titles, and TLS fingerprints.

The playbook at strix/skills/tooling/httpx.md emphasizes JSON output for automated filtering of 200/403 responses before sending to ffuf or Nuclei.

httpx -l urls.txt -status-code -content-length -title -silent -json -o httpx.jsonl

Phase 3: Vulnerability Discovery

Nuclei — Template-Based Scanning

When to use: Execute Nuclei against confirmed live hosts to rapidly test for known CVEs, misconfigurations, and policy violations at high throughput.

As documented in strix/skills/tooling/nuclei.md, this tool consumes the JSONL outputs from Naabu and httpx to run targeted templates without manual configuration.

nuclei -l targets.txt -as -s critical,high -rl 50 -c 20 -bs 20 -timeout 10 -retries 1 -silent -j -o nuclei.jsonl

ffuf — Fuzzing for Hidden Resources

When to use: Deploy ffuf after Katana has mapped the surface to brute-force hidden files, directories, parameters, or authentication bypasses via dictionary attacks.

The ffuf.md playbook specifies JSON output and match filters (e.g., -mc 200,403) to ensure only relevant findings enter the reporting pipeline.

ffuf -u https://app.example.com/FUZZ -w wordlist.txt -mc 200,403 -t 100 -json -o ffuf.jsonl

Phase 4: Vulnerability Validation

SQLMap — Automated SQL Injection Testing

When to use: Invoke SQLMap only after a potential injection vector has been identified (e.g., via ffuf or Katana logs) to confirm exploitability and assess database access levels.

The sqlmap.md playbook configures batch mode and conservative risk settings to prevent destructive operations while still proving vulnerability.

sqlmap -u "https://target.tld/item?id=1" -p id --batch --level 2 --risk 1 --threads 5 --timeout 10 --random-agent

Phase 5: Static Analysis

Semgrep — SAST and Secret Detection

When to use: Run Semgrep against source code repositories during CI/CD pipelines or early assessment phases to catch insecure patterns, hardcoded secrets, and OWASP Top 10 issues before deployment.

Defined in strix/skills/tooling/semgrep.md, this tool operates on filesystem paths rather than live hosts, making it the only non-network-based scanner in the suite.

semgrep scan --config p/default --metrics=off --json --output semgrep.json --quiet /workspace

Summary

• Strix packages nine security testing tools as modular skills under strix/skills/tooling/, each with a dedicated Markdown playbook.
• The strix/tools/registry.py module dynamically loads these tools, while strix/tools/executor.py runs them in sandboxed containers via the terminal_execute action defined in strix/tools/terminal/terminal_actions_schema.xml.
• Subfinder and Naabu handle initial reconnaissance; Nmap performs deep enumeration.
• Katana and httpx map web applications; ffuf discovers hidden resources.
• Nuclei scans for known vulnerabilities; SQLMap validates injection flaws.
• Semgrep provides static analysis for source code.
• All tools emit JSON/JSONL for consumption by strix/tools/reporting/reporting_actions.py, ensuring seamless data flow from discovery to final report generation.

Frequently Asked Questions

What is the complete list of security testing tools included in Strix?

Strix includes nine integrated tools: Subfinder (subdomain enumeration), Naabu (port scanning), Nmap (service discovery), Katana (web crawling), httpx (HTTP probing), ffuf (fuzzing), Nuclei (vulnerability scanning), SQLMap (SQL injection testing), and Semgrep (static code analysis). Each tool is configured via a Markdown playbook in strix/skills/tooling/.

How does Strix decide which security testing tool to run?

Agents select tools based on the current scan mode (quick, standard, or deep) and the assessment phase. The strix/tools/registry.py exposes all available skills, and the agent logic—guided by the playbooks—determines whether to run passive reconnaissance (Subfinder), fast port scanning (Naabu), or active exploitation (SQLMap).

Can I add custom security testing tools to Strix?

Yes. The modular architecture allows you to add new tooling skills by creating a Markdown playbook in strix/skills/tooling/ and updating the registration logic in strix/tools/registry.py. You do not need to modify core agent code, provided the new tool supports JSON/JSONL output for compatibility with the reporting subsystem.

How does Strix ensure safe execution of these security testing tools?

All commands are executed inside sandboxed Docker containers managed by strix/tools/executor.py, which enforces resource limits and network isolation. Additionally, tools like SQLMap run with conservative --risk and --level settings by default, and the terminal_execute schema in strix/tools/terminal/terminal_actions_schema.xml defines strict timeouts to prevent runaway processes.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}