Strix

strix - AI-Driven Application Security Testing

Keyword: strix · ai pentest · vulnerability scan cli · strix ci

Only use Strix against systems you own or are explicitly authorized to test.

Strix is an AI-driven application security CLI. It runs scans inside a Docker-backed sandbox, uses an LLM provider for reasoning, and can assess local directories, GitHub repositories, live URLs, domains, and multi-target combinations.

When to use this skill

• Install Strix and verify Docker plus sandbox readiness
• Configure STRIX_LLM, LLM_API_KEY, optional LLM_API_BASE, and related runtime settings
• Run local white-box scans against a repository or directory
• Run black-box or grey-box scans against staging or production-like URLs you are authorized to test
• Pass credentials, scope, or rules of engagement with --instruction or --instruction-file
• Choose the right scan depth: quick, standard, or deep
• Run Strix headlessly in CI/CD and interpret exit codes
• Understand Strix's internal security "skills" and how they differ from this repo's skills

Instructions

Step 1: Install and preflight

1. Run bash scripts/install.sh
2. Confirm strix --version succeeds
3. Ensure Docker is installed and the daemon is running
4. Let the installer pull the sandbox image on first setup unless you intentionally skip it
5. For manual installation alternatives and direct commands, see references/commands.md

Step 2: Configure the model provider

Set the minimum required environment variables before running a scan:

export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="your-api-key"

Optional runtime variables:

• LLM_API_BASE for OpenAI-compatible proxies or local endpoints
• PERPLEXITY_API_KEY for web search during scans
• STRIX_REASONING_EFFORT to tune model effort
• STRIX_DISABLE_BROWSER=true when UI automation is unnecessary
• STRIX_TELEMETRY=0 to disable telemetry defaults

Provider examples, config-file format, and optional environment variables are in references/providers-and-config.md.

Step 3: Pick the target and scan mode

Strix accepts these target types:

• Local directory: ./app
• GitHub repository URL: https://github.com/org/repo
• Live web app URL: https://staging.example.com
• Domain or IP
• Multi-target scans via repeated --target or -t

Scan modes:

• quick: PR checks, smoke tests, fast CI feedback
• standard: routine security reviews
• deep: default full assessment and longer bug-bounty-style exploration

Detailed mode and CI guidance lives in references/scan-modes-and-ci.md.

Step 4: Run the scan

Use bash scripts/run-scan.sh for a repeatable wrapper or call strix directly.

Common direct commands:

strix --target ./app
strix --target https://github.com/org/repo
strix --target https://staging.example.com --instruction-file ./instruction.md
strix -t https://github.com/org/repo -t https://staging.example.com

When authenticated or scoped testing matters, prefer --instruction-file over long inline prompts so credentials, exclusions, and rules of engagement stay explicit and reviewable.

Step 5: Review outputs and iterate

Strix stores results under strix_runs/<run-name>.

Exit codes to remember:

• 0: completed without findings
• 1: execution or environment error
• 2: vulnerabilities found in headless mode

Use the run artifacts to confirm what Strix tested, what it found, and what needs revalidation after fixes.

Step 6: Automate in CI/CD

Use headless mode in automation:

strix -n --target ./ --scan-mode quick

CI runners need Docker access. For pull requests, default to quick; reserve standard or deep for scheduled or release-stage jobs. See references/scan-modes-and-ci.md and scripts/ci-scan.sh.

Step 7: Understand Strix internal skills

Strix has its own internal security knowledge packs under strix/skills/. They are not the same as this repo's agent skills.

• Strix auto-selects up to 5 relevant internal skills per task
• Categories include vulnerabilities, frameworks, technologies, protocols, and tooling
• These internal skills enrich Strix agent behavior during the scan itself

See references/built-in-skills.md before assuming "skill" means the same thing across both ecosystems.

Examples

Example 1: Quick PR scan of a local repository

export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="your-api-key"
strix -n --target ./ --scan-mode quick

Example 2: Standard scan of a GitHub repository

strix --target https://github.com/acme/payments --scan-mode standard

Example 3: Grey-box scan of a staging URL

strix --target https://staging.example.com \
  --instruction-file ./instruction.md \
  --scan-mode deep

Example 4: Combined repo plus live target

strix -t https://github.com/acme/payments \
  -t https://staging.example.com \
  --instruction "Correlate source paths with exposed runtime issues"

Example 5: Browser-disabled API-focused scan

STRIX_DISABLE_BROWSER=true \
strix --target https://api.example.com --scan-mode standard

Example 6: Scripted run wrapper

bash scripts/run-scan.sh \
  --target ./app \
  --scan-mode quick \
  --non-interactive

Best practices

1. Only test assets you own or are explicitly permitted to assess.
2. Start with quick in CI and widen depth only when signal justifies the extra runtime.
3. Keep secrets in environment variables, secret stores, or instruction files under your control instead of scattering them inline.
4. Use both source and live targets together when you need better reproduction and remediation context.
5. Expect the first run to be slower because Strix may pull its sandbox image.
6. Treat strix_runs/ as evidence: archive useful runs, especially when findings are heading into triage or remediation.
7. Be explicit about scope, exclusions, credentials, and rate limits so Strix does not waste time exploring irrelevant surfaces.
8. Distinguish this repo's strix skill from Strix internal skills to avoid instruction confusion.

References

• references/commands.md
• references/providers-and-config.md
• references/scan-modes-and-ci.md
• references/built-in-skills.md
• scripts/install.sh
• scripts/run-scan.sh
• scripts/ci-scan.sh
• Strix GitHub Repository
• Strix Documentation