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

Run bash scripts/install.sh
Confirm strix --version succeeds
Ensure Docker is installed and the daemon is running
Let the installer pull the sandbox image on first setup unless you intentionally skip it
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

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

strix