| name | strix |
| description | Install, configure, and operate Strix for AI-driven application security testing. Use when you need to run authorized vulnerability scans against local codebases, GitHub repositories, staging URLs, domains, or CI pipelines; configure Docker and LLM providers; choose quick, standard, or deep scan depth; or pass authenticated testing instructions to Strix. Triggers on: strix, ai pentest, vulnerability scan cli, appsec scan, bug bounty automation, strix ci, strix docker, strix scan mode, strix instruction file, headless security scan.
|
| allowed-tools | Bash Read Write Edit Glob Grep WebFetch |
| compatibility | Requires Docker access and a configured LLM provider or compatible OpenAI-style endpoint. The CLI installs a native binary and pulls a sandbox image on first run. |
| license | Apache-2.0 |
| metadata | {"tags":"strix, appsec, pentest, vulnerability-scan, ci-cd, docker, llm, security-testing, bug-bounty, browser-automation","version":"1.0","source":"https://github.com/usestrix/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
- 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.
References