first commit
This commit is contained in:
Zakaria
@@ -0,0 +1,130 @@
|
||||
---
|
||||
title: "Configuration"
|
||||
description: "Environment variables for Strix"
|
||||
---
|
||||
|
||||
Configure Strix using environment variables or a config file.
|
||||
|
||||
## LLM Configuration
|
||||
|
||||
<ParamField path="STRIX_LLM" type="string" required>
|
||||
Model name in LiteLLM format (e.g., `openai/gpt-5.4`, `anthropic/claude-sonnet-4-6`).
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="LLM_API_KEY" type="string">
|
||||
API key for your LLM provider. Not required for local models or cloud provider auth (Vertex AI, AWS Bedrock).
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="LLM_API_BASE" type="string">
|
||||
Custom API base URL. Also accepts `OPENAI_API_BASE`, `LITELLM_BASE_URL`, or `OLLAMA_API_BASE`.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="LLM_TIMEOUT" default="300" type="integer">
|
||||
Request timeout in seconds for LLM calls.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="STRIX_LLM_MAX_RETRIES" default="5" type="integer">
|
||||
Maximum number of retries for LLM API calls on transient failures.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="STRIX_REASONING_EFFORT" default="high" type="string">
|
||||
Control thinking effort for reasoning models. Valid values: `none`, `minimal`, `low`, `medium`, `high`, `xhigh`. Defaults to `medium` for quick scan mode.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="STRIX_MEMORY_COMPRESSOR_TIMEOUT" default="30" type="integer">
|
||||
Timeout in seconds for memory compression operations (context summarization).
|
||||
</ParamField>
|
||||
|
||||
## Optional Features
|
||||
|
||||
<ParamField path="PERPLEXITY_API_KEY" type="string">
|
||||
API key for Perplexity AI. Enables real-time web search during scans for OSINT and vulnerability research.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="STRIX_TELEMETRY" default="1" type="string">
|
||||
Telemetry toggle. Set to `0`, `false`, `no`, or `off` to disable telemetry (PostHog, Scarf, OTEL).
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="TRACELOOP_BASE_URL" type="string">
|
||||
OTLP/Traceloop base URL for remote OpenTelemetry export. If unset, Strix keeps traces local only.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="TRACELOOP_API_KEY" type="string">
|
||||
API key used for remote trace export. Remote export is enabled only when both `TRACELOOP_BASE_URL` and `TRACELOOP_API_KEY` are set.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="TRACELOOP_HEADERS" type="string">
|
||||
Optional custom OTEL headers (JSON object or `key=value,key2=value2`). Useful for Langfuse or custom/self-hosted OTLP gateways.
|
||||
</ParamField>
|
||||
|
||||
When remote OTEL vars are not set, Strix still writes complete run telemetry locally to:
|
||||
|
||||
```bash
|
||||
strix_runs/<run_name>/events.jsonl
|
||||
```
|
||||
|
||||
When remote vars are set, Strix dual-writes telemetry to both local JSONL and the remote OTEL endpoint.
|
||||
|
||||
## Docker Configuration
|
||||
|
||||
<ParamField path="STRIX_IMAGE" default="ghcr.io/usestrix/strix-sandbox:1.0.0" type="string">
|
||||
Docker image to use for the sandbox container.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="DOCKER_HOST" type="string">
|
||||
Docker daemon socket path. Use for remote Docker hosts or custom configurations.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="STRIX_RUNTIME_BACKEND" default="docker" type="string">
|
||||
Runtime backend for the sandbox environment.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="STRIX_MAX_LOCAL_COPY_MB" default="1024" type="integer">
|
||||
Maximum size (in MB) of a local directory target that Strix will copy into the sandbox file-by-file. Larger targets exit early with a suggestion to use `--mount` instead. Set to `0` to disable the check.
|
||||
</ParamField>
|
||||
|
||||
## Sandbox Configuration
|
||||
|
||||
<ParamField path="STRIX_SANDBOX_EXECUTION_TIMEOUT" default="120" type="integer">
|
||||
Maximum execution time in seconds for sandbox operations.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="STRIX_SANDBOX_CONNECT_TIMEOUT" default="10" type="integer">
|
||||
Timeout in seconds for connecting to the sandbox container.
|
||||
</ParamField>
|
||||
|
||||
## Config File
|
||||
|
||||
Strix stores configuration in `~/.strix/cli-config.json`. You can also specify a custom config file:
|
||||
|
||||
```bash
|
||||
strix --target ./app --config /path/to/config.json
|
||||
```
|
||||
|
||||
**Config file format:**
|
||||
|
||||
```json
|
||||
{
|
||||
"env": {
|
||||
"STRIX_LLM": "openai/gpt-5.4",
|
||||
"LLM_API_KEY": "sk-...",
|
||||
"STRIX_REASONING_EFFORT": "high"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Example Setup
|
||||
|
||||
```bash
|
||||
# Required
|
||||
export STRIX_LLM="openai/gpt-5.4"
|
||||
export LLM_API_KEY="sk-..."
|
||||
|
||||
# Optional: Enable web search
|
||||
export PERPLEXITY_API_KEY="pplx-..."
|
||||
|
||||
# Optional: Custom timeouts
|
||||
export LLM_TIMEOUT="600"
|
||||
export STRIX_SANDBOX_EXECUTION_TIMEOUT="300"
|
||||
|
||||
```
|
||||
@@ -0,0 +1,136 @@
|
||||
---
|
||||
title: "Skills"
|
||||
description: "Specialized knowledge packages that enhance agent capabilities"
|
||||
---
|
||||
|
||||
Skills are structured knowledge packages that give Strix agents deep expertise in specific vulnerability types, technologies, and testing methodologies.
|
||||
|
||||
## The Idea
|
||||
|
||||
LLMs have broad but shallow security knowledge. They know _about_ SQL injection, but lack the nuanced techniques that experienced pentesters use—parser quirks, bypass methods, validation tricks, and chain attacks.
|
||||
|
||||
Skills inject this deep, specialized knowledge directly into the agent's context, transforming it from a generalist into a specialist for the task at hand.
|
||||
|
||||
## How They Work
|
||||
|
||||
When Strix spawns an agent for a specific task, it selects up to 5 relevant skills based on the context:
|
||||
|
||||
```python
|
||||
# Agent created for JWT testing automatically loads relevant skills
|
||||
create_agent(
|
||||
task="Test authentication mechanisms",
|
||||
skills=["authentication_jwt", "business_logic"]
|
||||
)
|
||||
```
|
||||
|
||||
The skills are injected into the agent's system prompt, giving it access to:
|
||||
|
||||
- **Advanced techniques** — Non-obvious methods beyond standard testing
|
||||
- **Working payloads** — Practical examples with variations
|
||||
- **Validation methods** — How to confirm findings and avoid false positives
|
||||
|
||||
## Skill Categories
|
||||
|
||||
### Vulnerabilities
|
||||
|
||||
Core vulnerability classes with deep exploitation techniques.
|
||||
|
||||
| Skill | Coverage |
|
||||
| ------------------------------------- | ------------------------------------------------------ |
|
||||
| `authentication_jwt` | JWT attacks, algorithm confusion, claim tampering |
|
||||
| `idor` | Object reference attacks, horizontal/vertical access |
|
||||
| `sql_injection` | SQL injection variants, WAF bypasses, blind techniques |
|
||||
| `xss` | XSS types, filter bypasses, DOM exploitation |
|
||||
| `ssrf` | Server-side request forgery, protocol handlers |
|
||||
| `csrf` | Cross-site request forgery, token bypasses |
|
||||
| `xxe` | XML external entities, OOB exfiltration |
|
||||
| `rce` | Remote code execution vectors |
|
||||
| `business_logic` | Logic flaws, state manipulation, race conditions |
|
||||
| `race_conditions` | TOCTOU, parallel request attacks |
|
||||
| `path_traversal_lfi_rfi` | File inclusion, path traversal |
|
||||
| `open_redirect` | Redirect bypasses, URL parsing tricks |
|
||||
| `mass_assignment` | Attribute injection, hidden parameter pollution |
|
||||
| `insecure_file_uploads` | Upload bypasses, extension tricks |
|
||||
| `information_disclosure` | Data leakage, error-based enumeration |
|
||||
| `subdomain_takeover` | Dangling DNS, cloud resource claims |
|
||||
| `broken_function_level_authorization` | Privilege escalation, role bypasses |
|
||||
|
||||
### Frameworks
|
||||
|
||||
Framework-specific testing patterns.
|
||||
|
||||
| Skill | Coverage |
|
||||
| --------- | -------------------------------------------- |
|
||||
| `fastapi` | FastAPI security patterns, Pydantic bypasses |
|
||||
| `nextjs` | Next.js SSR/SSG issues, API route security |
|
||||
|
||||
### Technologies
|
||||
|
||||
Third-party service and platform security.
|
||||
|
||||
| Skill | Coverage |
|
||||
| -------------------- | ---------------------------------- |
|
||||
| `supabase` | Supabase RLS bypasses, auth issues |
|
||||
| `firebase_firestore` | Firestore rules, Firebase auth |
|
||||
|
||||
### Protocols
|
||||
|
||||
Protocol-specific testing techniques.
|
||||
|
||||
| Skill | Coverage |
|
||||
| --------- | ------------------------------------------------ |
|
||||
| `graphql` | GraphQL introspection, batching, resolver issues |
|
||||
|
||||
### Tooling
|
||||
|
||||
Sandbox CLI playbooks for core recon and scanning tools.
|
||||
|
||||
| Skill | Coverage |
|
||||
| ----------- | ------------------------------------------------------- |
|
||||
| `nmap` | Port/service scan syntax and high-signal scan patterns |
|
||||
| `nuclei` | Template selection, severity filtering, and rate tuning |
|
||||
| `httpx` | HTTP probing and fingerprint output patterns |
|
||||
| `ffuf` | Wordlist fuzzing, matcher/filter strategy, recursion |
|
||||
| `subfinder` | Passive subdomain enumeration and source control |
|
||||
| `naabu` | Fast port scanning with explicit rate/verify controls |
|
||||
| `katana` | Crawl depth/JS/known-files behavior and pitfalls |
|
||||
| `sqlmap` | SQLi workflow for enumeration and controlled extraction |
|
||||
|
||||
## Skill Structure
|
||||
|
||||
Each skill is a Markdown file with YAML frontmatter for metadata:
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: skill_name
|
||||
description: Brief description of the skill's coverage
|
||||
---
|
||||
|
||||
# Skill Title
|
||||
|
||||
Key insight about this vulnerability or technique.
|
||||
|
||||
## Attack Surface
|
||||
What this skill covers and where to look.
|
||||
|
||||
## Methodology
|
||||
Step-by-step testing approach.
|
||||
|
||||
## Techniques
|
||||
How to discover and exploit the vulnerability.
|
||||
|
||||
## Bypass Methods
|
||||
How to bypass common protections.
|
||||
|
||||
## Validation
|
||||
How to confirm findings and avoid false positives.
|
||||
```
|
||||
|
||||
## Contributing Skills
|
||||
|
||||
Community contributions are welcome. Create a `.md` file in the appropriate category with YAML frontmatter (`name` and `description` fields). Good skills include:
|
||||
|
||||
1. **Real-world techniques** — Methods that work in practice
|
||||
2. **Practical payloads** — Working examples with variations
|
||||
3. **Validation steps** — How to confirm without false positives
|
||||
4. **Context awareness** — Version/environment-specific behavior
|
||||
Reference in New Issue
Block a user