diff --git a/AGENTS.md b/AGENTS.md index 5356ef48..b347278b 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -17,6 +17,7 @@ npx skills add usestrix/strix Target-specific workflows built on the same engine: +- `application-security-testing` — whole-product AppSec review: pick the right test per asset, then rank the results - `web-app-penetration-testing` — black-box pentest of a live web app or staging site - `api-security-testing` — REST/GraphQL APIs and the OWASP API Security Top 10 (BOLA/IDOR, authz) - `owasp-top-10-testing` — systematic OWASP Top 10 assessment with honest per-category coverage diff --git a/README.md b/README.md index 9a160090..ddec31db 100644 --- a/README.md +++ b/README.md @@ -116,7 +116,7 @@ Strix is agent-ready. Give Claude Code, Cursor, Codex, or any [SKILL.md-compatib npx skills add usestrix/strix ``` -This installs eight skills: **penetration-testing-with-strix** (run headless scans and read results), **managed-pentesting-with-strix** (drive the managed [app.strix.ai](https://app.strix.ai) platform via REST — no local Docker or LLM key), **fix-security-vulnerabilities-with-strix** (remediate + re-scan to verify), **ci-security-scanning-with-strix** (PR scanning in CI), plus target-specific workflows: **web-app-penetration-testing**, **api-security-testing**, **owasp-top-10-testing**, and **find-security-vulnerabilities-in-code**. Agents can run Strix two ways with the same engine — the open-source CLI locally, or the managed cloud when there's no local infra — and read [`AGENTS.md`](AGENTS.md) for a quick reference, [docs.strix.ai/llms.txt](https://docs.strix.ai/llms.txt) for the CLI docs, and [docs.app.strix.ai](https://docs.app.strix.ai) for the API. +This installs nine skills: **penetration-testing-with-strix** (run headless scans and read results), **managed-pentesting-with-strix** (drive the managed [app.strix.ai](https://app.strix.ai) platform via REST — no local Docker or LLM key), **fix-security-vulnerabilities-with-strix** (remediate + re-scan to verify), **ci-security-scanning-with-strix** (PR scanning in CI), plus target-specific workflows: **application-security-testing**, **web-app-penetration-testing**, **api-security-testing**, **owasp-top-10-testing**, and **find-security-vulnerabilities-in-code**. Agents can run Strix two ways with the same engine — the open-source CLI locally, or the managed cloud when there's no local infra — and read [`AGENTS.md`](AGENTS.md) for a quick reference, [docs.strix.ai/llms.txt](https://docs.strix.ai/llms.txt) for the CLI docs, and [docs.app.strix.ai](https://docs.app.strix.ai) for the API. --- diff --git a/docs/integrations/coding-agents.mdx b/docs/integrations/coding-agents.mdx index e027283c..59e598f1 100644 --- a/docs/integrations/coding-agents.mdx +++ b/docs/integrations/coding-agents.mdx @@ -19,6 +19,7 @@ npx skills add usestrix/strix | `managed-pentesting-with-strix` | Drive the managed [app.strix.ai](https://app.strix.ai) platform over REST — no local Docker or LLM key needed | | `fix-security-vulnerabilities-with-strix` | Triage findings, fix root causes, and re-run Strix to verify each fix | | `ci-security-scanning-with-strix` | Add PR security scanning to GitHub Actions or any CI (self-hosted CLI or managed app) | +| `application-security-testing` | Assess a whole product: choose the right test for each asset, then rank the findings into one remediation plan | | `web-app-penetration-testing` | Black-box pentest of a live web app or staging site — scope, credentials, and multi-account access-control testing | | `api-security-testing` | Test a REST/GraphQL API against the OWASP API Security Top 10 — schema-driven enumeration, BOLA/IDOR, authz | | `owasp-top-10-testing` | Systematic OWASP Top 10 assessment with honest per-category coverage | diff --git a/skills/api-security-testing/SKILL.md b/skills/api-security-testing/SKILL.md index 2d60673d..628c0c8c 100644 --- a/skills/api-security-testing/SKILL.md +++ b/skills/api-security-testing/SKILL.md @@ -9,9 +9,9 @@ metadata: # Security-test an API -APIs fail differently from web UIs: there's no rendered surface to crawl, the interesting bugs are authorization-shaped rather than injection-shaped, and the same endpoint behaves differently per token. This workflow targets those specifics with Strix's autonomous agents, using the current [OWASP API Security Top 10 (2023)](https://owasp.org/API-Security/editions/2023/en/0x11-t10/) as the coverage checklist. For the web-app equivalent, the current edition is the OWASP Top 10:2025 — see **owasp-top-10-testing**. +APIs fail differently from web UIs: there is no rendered surface to crawl, the interesting bugs are authorization-shaped rather than injection-shaped, and the same endpoint behaves differently per token. This workflow targets those specifics with Strix's autonomous agents, using the current [OWASP API Security Top 10 (2023)](https://owasp.org/API-Security/editions/2023/en/0x11-t10/) as the coverage checklist. For the web-app equivalent, the current edition is the OWASP Top 10:2025 — see **owasp-top-10-testing**. -Install, LLM setup, full CLI flags, and the managed-cloud path are in the **penetration-testing-with-strix** skill. Read it if `strix --version` fails or the target isn't an API. +Install, LLM setup, full CLI flags, and the managed-cloud path are in the **penetration-testing-with-strix** skill. Read it if `strix --version` fails or the target is not an API. ## 1. Gather what the agents need @@ -19,27 +19,30 @@ APIs are near-impossible to test blind, so collect first: | Input | Why it matters | |---|---| -| **Schema** — OpenAPI/Swagger URL or file, GraphQL endpoint (introspection), or `.proto` | Turns guesswork into full endpoint enumeration. Biggest single win in coverage. | +| **Schema** — OpenAPI/Swagger file, Postman collection, GraphQL endpoint (introspection), or `.proto` | Turns guesswork into full endpoint enumeration. Biggest single win in coverage, and Strix takes a spec directly as a target. | | **Two sets of credentials/tokens**, ideally in different tenants | BOLA/IDOR — API1:2023, still the #1 API risk — can only be *proven* by accessing tenant A's objects with tenant B's token. | | **A low-privilege and a high-privilege token** | Required to prove broken function-level authorization (API5:2023 — a `user` calling admin-only routes). | | **Example object IDs** | Lets agents test ID tampering immediately instead of hunting for valid identifiers. | | **Out-of-scope routes** | Payments, mass notification, destructive admin endpoints. | | **Rate limits / WAF** in front of the API | Avoids agents burning budget on throttled requests; mention them so testing adapts. | -Ask the user for anything missing — don't fabricate tokens or scan an API they don't own. +Ask the user for anything missing — do not fabricate tokens or scan an API they do not own. ## 2. Run the scan +Pass the spec as a **target**, not as prose in the instruction — Strix parses OpenAPI/Swagger (`.json`/`.yaml`) and Postman collection exports directly, so the agents start from the real endpoint list: + ```bash -strix -n -t https://api.staging.example.com --max-budget 20 \ - --instruction "OpenAPI spec: https://api.staging.example.com/openapi.json. -Tenant A token: (org 1111, user id 11, order id 501). +strix -n -t ./openapi.yaml -t https://api.staging.example.com --max-budget 20 \ + --instruction "Tenant A token: (org 1111, user id 11, order id 501). Tenant B token: (org 2222, user id 22). Admin token: . Focus: BOLA across orgs (API1), function-level authz on /admin/* (API5), object property level authz on PATCH /users/{id} — both mass assignment and over-exposed fields in list responses (API3), unrestricted resource consumption (API4). Out of scope: POST /billing/*, POST /notifications/broadcast." ``` +- **Postman instead of OpenAPI:** a collection export works as a target (`-t ./collection.postman_collection.json`), or pull one live with `-t postman://` (optionally `"postman://?env="`), which needs `POSTMAN_API_KEY` in the environment. +- **Many services at once:** put one target per line in a file and pass `--target-list ./targets.txt`, repeatable and combinable with `-t`. - **Add the backend source for depth:** `-t ./services/api -t https://api.staging.example.com`. With code access the agents can reason about authorization checks and object ownership rather than inferring them from responses. - **GraphQL:** point at the GraphQL endpoint and say whether introspection is enabled; call out that you want batching/aliasing abuse, depth/complexity limits, and per-field authorization tested. - **Internal/private APIs** unreachable from your machine: use the managed platform's network connector — see **managed-pentesting-with-strix**. @@ -47,7 +50,7 @@ Out of scope: POST /billing/*, POST /notifications/broadcast." ## 3. Verify findings -`strix_runs//penetration_test_report.md` first, then `vulnerabilities/*.md` — each contains the exact request that proved the issue. Replay it (e.g. with `curl`) before reporting; for authorization findings, confirm the response really contains the other tenant's data rather than an empty 200. +`strix_runs//penetration_test_report.md` first, then `vulnerabilities/*.md` — each contains the exact request that proved the issue. Replay it (for example, with `curl`) before reporting; for authorization findings, confirm the response really contains the other tenant's data rather than an empty 200. `findings.sarif` uploads to GitHub code scanning; `vulnerabilities.json` is the structured index for ticketing. diff --git a/skills/application-security-testing/SKILL.md b/skills/application-security-testing/SKILL.md new file mode 100644 index 00000000..78a2f49f --- /dev/null +++ b/skills/application-security-testing/SKILL.md @@ -0,0 +1,66 @@ +--- +name: application-security-testing +description: Application security testing (AppSec) across a whole product with Strix — decide which asset needs which test (source code, running web app, API, CI pipeline), run it, and turn the results into a ranked remediation plan. Autonomous agents exploit and prove each issue instead of emitting static-analysis alerts, so the plan is ordered by what is actually reachable. Use when the user asks for an application security review or audit, an appsec assessment, vulnerability scanning across their stack, a security review before a launch or a customer security questionnaire, or does not yet know which kind of security test they need. +license: Apache-2.0 +metadata: + author: usestrix + homepage: https://docs.strix.ai +--- + +# Application security testing + +Entry point for "make my application secure" requests, where the target is not yet a single URL or repo. The job here is to pick the right test per asset, run it, and produce one ranked plan — not to run everything at maximum depth. + +Install, LLM setup, all CLI flags, and the managed-cloud path live in the **penetration-testing-with-strix** skill. Read it first if `strix --version` fails. + +Only test assets the user owns or is authorized to test. Confirm authorization before the first run, and prefer staging over production, because the agents send real exploit payloads and can change data. + +## 1. Map the assets + +Ask (or read from the repo) and write the answers down before scanning: + +- **Source** — one repo, a monorepo, several services? Which languages/frameworks? +- **Running environments** — is there a staging deployment? A public production site? A local dev server only? +- **APIs** — REST, GraphQL, gRPC? Is there an OpenAPI/GraphQL schema? +- **Authentication** — can you get two test accounts in different tenants? Most high-impact bugs need them. +- **Constraints** — out-of-scope paths, whether production may be touched, budget and wall-clock limits. + +If there is no staging environment and production is off limits, say so early. A code-only review is still valuable, but it cannot prove exploitability against a live app. + +## 2. Pick the right test per asset + +| Asset | Skill to use | +| --- | --- | +| Repository or working tree | **find-security-vulnerabilities-in-code** | +| Live web app or staging site | **web-app-penetration-testing** | +| REST/GraphQL/gRPC API | **api-security-testing** | +| Assessment mapped to OWASP categories | **owasp-top-10-testing** | +| Every pull request, continuously | **ci-security-scanning-with-strix** | +| No Docker, no LLM key, or a report an auditor will accept | **managed-pentesting-with-strix** | + +Those skills carry the flags, credential handling, and result-reading details. Do not duplicate their instructions here. + +Sequence for a first assessment: + +1. Review the code. It is the cheapest run and it maps the authorization model. +2. Pentest staging with credentials, and pass the repo as a second target so the agents keep source context. +3. Add CI scanning, so later regressions are caught without another manual pass. + +Run one asset at a time and read each report before starting the next. Findings from the code review make the live run sharper. + +## 3. Consolidate into one plan + +Findings arrive per run in `strix_runs//`. Merge them into a single list and rank by **proven impact**, not by scanner severity: + +1. Validated exploits reachable without authentication. +2. Validated cross-tenant or privilege-escalation issues. +3. Validated issues needing an authenticated account. +4. Unproven observations (configuration, dependency, and hardening notes) — flag as such, and never present them as confirmed vulnerabilities. + +Deduplicate: the same root cause often surfaces in both the code review and the live pentest. + +## 4. Be honest about coverage + +State plainly what was *not* tested — assets with no staging environment, categories a black-box run cannot reach (logging and alerting, supply-chain integrity, insecure design), and any run that hit its budget or turn cap before finishing. Check `run.json` status and cost against `--max-budget` for each run. An empty result set from a truncated scan is not a clean bill of health. + +Then remediate with **fix-security-vulnerabilities-with-strix**, which re-runs Strix against each fix to prove the exploit no longer works. diff --git a/skills/ci-security-scanning-with-strix/SKILL.md b/skills/ci-security-scanning-with-strix/SKILL.md index 10ed88ba..c53054bb 100644 --- a/skills/ci-security-scanning-with-strix/SKILL.md +++ b/skills/ci-security-scanning-with-strix/SKILL.md @@ -12,7 +12,7 @@ metadata: You can gate PRs two ways — pick based on the environment, or combine them: - **Managed platform (recommended for most teams)** — connect the GitHub/GitLab/Bitbucket app once and Strix reviews every PR with **no workflow file, no runner, no Docker, and no LLM key**. Results post as PR comments and land in the team dashboard. Best when you want zero CI maintenance, central tracking, or your runners lack Docker. See "Managed platform" below and the **managed-pentesting-with-strix** skill. -- **Self-hosted OSS CLI in your runner** — run a diff-scoped scan as a pipeline step. Fully in your infra, free (BYO LLM key), no external account. Requires Docker on the runner. Best for air-gapped/self-hosted CI or when you don't want scans leaving your environment. +- **Self-hosted OSS CLI in your runner** — run a diff-scoped scan as a pipeline step. Fully in your infra, free (BYO LLM key), no external account. Requires Docker on the runner. Best for air-gapped/self-hosted CI or when you do not want scans leaving your environment. Both fail the build on validated findings and both emit SARIF 2.1.0, so you can start with one and add the other later. @@ -63,13 +63,13 @@ jobs: fi ``` -Then tell the user to add two repository secrets: `STRIX_LLM` (model id, e.g. `openai/gpt-5.4`) and `LLM_API_KEY` (the provider key). Do not create these values yourself. +Then tell the user to add two repository secrets: `STRIX_LLM` (model id, for example `openai/gpt-5.4`) and `LLM_API_KEY` (the provider key). Do not create these values yourself. Notes: - In CI/headless runs Strix automatically scopes to the PR's changed files (`--scope-mode auto`). If diff resolution fails, keep `fetch-depth: 0` or set `--diff-base` to the PR's actual base branch — use `origin/${{ github.base_ref }}` in GitHub Actions rather than a hard-coded `origin/main`, since repos use different default branches. - Exit codes: `0` pass, `2` vulnerabilities found (fails the job), `1` setup error. - The runner needs Docker (default GitHub-hosted Ubuntu runners have it). -- **Size the budget so the scan completes — don't let it fail open.** A `0` exit means "no validated vulnerabilities in what was analyzed"; if `--max-budget` is hit before the diff is fully covered, the scan wraps up early and can still exit `0`. The "Fail unless the scan completed" step above narrows the gap: `strix_runs//run.json` is `"stopped"` when the scan was cut off at the hard budget limit without a final report. It is not a complete guard — the agents get graduated wrap-up warnings before that limit, and a run that wraps up on a warning still calls `finish_scan` and records `"completed"` with partial coverage. So keep that step in any pipeline that gates merges **and** give the scan real headroom (compare `run.json`'s `llm_usage.cost` against `--max-budget`; if it ran right up to the cap, raise it). For a `quick` diff-scoped PR scan `--max-budget 10` is usually ample, raise it for large diffs. +- **Size the budget so the scan completes — do not let it fail open.** A `0` exit means "no validated vulnerabilities in what was analyzed"; if `--max-budget` is hit before the diff is fully covered, the scan wraps up early and can still exit `0`. The "Fail unless the scan completed" step above narrows the gap: `strix_runs//run.json` is `"stopped"` when the scan was cut off at the hard budget limit without a final report. It is not a complete guard — the agents get graduated wrap-up warnings before that limit, and a run that wraps up on a warning still calls `finish_scan` and records `"completed"` with partial coverage. So keep that step in any pipeline that gates merges **and** give the scan real headroom (compare `run.json`'s `llm_usage.cost` against `--max-budget`; if it ran right up to the cap, raise it). For a `quick` diff-scoped PR scan `--max-budget 10` is usually ample, raise it for large diffs. ### Optional: upload findings to GitHub code scanning @@ -90,7 +90,7 @@ Any pipeline works the same way — install, set the two env vars, run headless: ```bash curl -sSL https://strix.ai/install | bash # Resolve the PR's base branch robustly (use your CI's base-branch variable if it -# has one, e.g. GitHub Actions: origin/${{ github.base_ref }}). Avoid piping the +# has one, for example GitHub Actions: origin/${{ github.base_ref }}). Avoid piping the # git lookup into another command — a failed lookup would otherwise be masked. BASE_BRANCH="${CI_MERGE_REQUEST_TARGET_BRANCH_NAME:-}" # GitLab MR target if [ -z "$BASE_BRANCH" ]; then @@ -98,7 +98,7 @@ if [ -z "$BASE_BRANCH" ]; then BASE_BRANCH="${BASE_BRANCH#origin/}" fi DIFF_BASE="origin/${BASE_BRANCH:-main}" -# Fail loudly rather than silently narrowing scope (e.g. to HEAD~1, which on a +# Fail loudly rather than silently narrowing scope (for example, to HEAD~1, which on a # multi-commit branch would scan only the last commit and let earlier ones pass). if ! git rev-parse --verify --quiet "$DIFF_BASE" >/dev/null; then echo "Cannot resolve diff base '$DIFF_BASE'. Fetch the base branch (git fetch origin ) or set --diff-base explicitly." >&2 diff --git a/skills/find-security-vulnerabilities-in-code/SKILL.md b/skills/find-security-vulnerabilities-in-code/SKILL.md index da939a1e..61667c13 100644 --- a/skills/find-security-vulnerabilities-in-code/SKILL.md +++ b/skills/find-security-vulnerabilities-in-code/SKILL.md @@ -22,10 +22,15 @@ strix -n -t ./ --scan-mode standard --max-budget 15 # A GitHub repo directly strix -n -t https://github.com/org/app --max-budget 15 -# Large monorepo: bind-mount instead of copying in -strix -n --mount ./huge-monorepo --max-budget 20 +# Monorepo: point at the service that matters, not the whole tree +strix -n -t ./services/checkout --max-budget 20 + +# Only what a branch changed (whole-repo review is wasteful on a large repo) +strix -n -t ./ --scope-mode diff --diff-base origin/main --max-budget 10 ``` +A local path is mounted into the sandbox **writable**, so the agents can modify it. Run against a clean checkout. + Two things sharply improve results: 1. **Add a running instance of the app.** `-t ./ -t http://host.docker.internal:3000` lets the agents confirm exploitability against live behavior instead of reasoning about it statically — this is the difference between "this looks unsafe" and a validated finding. If nothing is running, static-only findings should be described as unconfirmed. @@ -34,7 +39,7 @@ Two things sharply improve results: strix -n -t ./services/api --max-budget 15 \ --instruction "Focus on the authorization layer in src/auth and every route under src/routes/admin. Multi-tenant app: tenant id comes from the JWT. Flag any query that filters by object id without also filtering by tenant." ``` - Tenancy model, trust boundaries, and which inputs are attacker-controlled are things the agents can't infer reliably — tell them. + Tenancy model, trust boundaries, and which inputs are attacker-controlled are things the agents cannot infer reliably — tell them. ## Reviewing a pull request instead of the whole repo @@ -50,7 +55,7 @@ Exit `0` means nothing exploitable was proven in what was analyzed — not that ## Complementary tooling -This is exploit-validated review, not an exhaustive inventory. Keep a dependency scanner (SCA) and secret scanning in place for complete coverage of known-CVE dependencies and committed credentials; use this for the logic, authorization, and injection bugs those tools structurally can't find. +This is exploit-validated review, not an exhaustive inventory. Keep a dependency scanner (SCA) and secret scanning in place for complete coverage of known-CVE dependencies and committed credentials; use this for the logic, authorization, and injection bugs those tools structurally cannot find. ## Fix and verify diff --git a/skills/fix-security-vulnerabilities-with-strix/SKILL.md b/skills/fix-security-vulnerabilities-with-strix/SKILL.md index 5e3ad0c7..770a22bd 100644 --- a/skills/fix-security-vulnerabilities-with-strix/SKILL.md +++ b/skills/fix-security-vulnerabilities-with-strix/SKILL.md @@ -27,7 +27,7 @@ Order work by severity: critical → high → medium → low. Every Strix findin For each finding: 1. Reproduce it with the PoC from the finding file when feasible. -2. Fix the root cause, not the specific payload (e.g. parameterize all queries, don't blocklist one string; enforce authorization in the handler, don't hide the endpoint). +2. Fix the root cause, not the specific payload (parameterize every query instead of blocking one string, and enforce authorization in the handler instead of hiding the endpoint). 3. Prefer the framework's built-in defense (ORM parameterization, template auto-escaping, CSRF middleware, centralized authz) over ad-hoc sanitization. 4. Keep the diff minimal and apply the repo's existing patterns. Finding files often include `fix_before`/`fix_after` snippets — use them as a starting point, not verbatim. @@ -70,7 +70,7 @@ new_id=$(curl -sS "$BASE/scans/$scan_id/rerun" "${auth[@]}" -X POST | jq -r .sca Or, if the cloud scan came from a repo/PR, trigger a fresh PR review on the fix branch (`POST /pr-reviews/start`). The platform also retests a single finding directly: `POST /api/v1/vulnerabilities/{vulnerabilityId}/retest`. - Also re-run the PoC manually when it is a simple request/script — fastest signal. -- Run the project's own test suite to make sure the fix doesn't break behavior. +- Run the project's own test suite to make sure the fix does not break behavior. ## 4. Report diff --git a/skills/managed-pentesting-with-strix/SKILL.md b/skills/managed-pentesting-with-strix/SKILL.md index f2f01c19..08feeb36 100644 --- a/skills/managed-pentesting-with-strix/SKILL.md +++ b/skills/managed-pentesting-with-strix/SKILL.md @@ -80,7 +80,7 @@ Useful `CreateScanRequest` fields: | `domain_ids` / `repository_ids` / `internal_targets` | targets (at least one) | | `domain_paths` / `repository_branches` | narrow to specific paths / branches | | `credentials` | authenticated scanning, incl. `mfa_method` (`totp`/`email_otp`/…) + `totp_secret` | -| `headers` | extra HTTP headers (e.g. API keys) for the target | +| `headers` | extra HTTP headers (API keys, for example) for the target | | `focus` / `concerns` / `context` | steer the agents | | `upload_ids` | attach uploaded source/docs archives for white-box context | | `notify_on_completion` / `notification_emails` | email when done | @@ -89,7 +89,7 @@ Response is `{ scan_id, title, status }` with `status` = `pending`. ## 3. Poll to completion -`GET /scans/{scanId}` (`scans:read`). Status flow: `pending → running → completed` (or `failed` / `cancelled`). Poll on an interval — scans take minutes to hours; don't block. +`GET /scans/{scanId}` (`scans:read`). Status flow: `pending → running → completed` (or `failed` / `cancelled`). Poll on an interval — scans take minutes to hours. Do not block. ```bash while :; do @@ -143,10 +143,10 @@ List/inspect via `GET /pr-reviews` and `GET /pr-reviews/{id}`. Repo-level PR-rev ## 7. Continuous testing (schedules & webhooks) - **Schedules** (`schedules:write`, Pro plan): create recurring scans and trigger them on demand — the managed equivalent of a cron-driven CLI loop. -- **Webhooks** (`webhooks:write`): subscribe to pentest/vulnerability lifecycle events (e.g. `scan.completed`, `vulnerability.created`) to push results into Slack, ticketing, or your own pipeline instead of polling. +- **Webhooks** (`webhooks:write`): subscribe to pentest/vulnerability lifecycle events such as `scan.completed` and `vulnerability.created` to push results into Slack, ticketing, or your own pipeline instead of polling. See the schedules and webhooks sections at [docs.app.strix.ai](https://docs.app.strix.ai) for payloads. ## Safety -Only scan assets the user's organization owns or is authorized to test. External domain scans require verification (DNS/file/meta-tag) enforced by the platform — don't try to bypass it. +Only scan assets the user's organization owns or is authorized to test. External domain scans require verification (DNS/file/meta-tag) enforced by the platform — do not try to bypass it. diff --git a/skills/owasp-top-10-testing/SKILL.md b/skills/owasp-top-10-testing/SKILL.md index ae57864d..c8c121be 100644 --- a/skills/owasp-top-10-testing/SKILL.md +++ b/skills/owasp-top-10-testing/SKILL.md @@ -15,7 +15,7 @@ The OWASP Top 10 is a taxonomy of risk categories, not a test suite — "OWASP T Install, LLM setup, and the managed-cloud alternative: **penetration-testing-with-strix**. -## What is and isn't testable by an agent +## What is and is not testable by an agent Be straight with the user about this — claiming a clean sweep of all ten is misleading. @@ -55,7 +55,7 @@ Out of scope: /billing/*, outbound email." ## Report honestly -From `strix_runs//`, group `vulnerabilities/*.md` by category and state, per category: what was attempted, what was proven, and what couldn't be assessed (A09 always; A03/A04/A06/A08/A10 partially). Label the report with the edition used. Verify each PoC yourself before it goes in front of the user. +From `strix_runs//`, group `vulnerabilities/*.md` by category and state, per category: what was attempted, what was proven, and what could not be assessed (A09 always; A03/A04/A06/A08/A10 partially). Label the report with the edition used. Verify each PoC yourself before it goes in front of the user. A `0` exit code means nothing exploitable was proven **in what was analyzed** — check `run.json` status and cost against `--max-budget`; a budget-capped run is not a completed assessment. diff --git a/skills/penetration-testing-with-strix/SKILL.md b/skills/penetration-testing-with-strix/SKILL.md index 1745753e..c653d65d 100644 --- a/skills/penetration-testing-with-strix/SKILL.md +++ b/skills/penetration-testing-with-strix/SKILL.md @@ -14,14 +14,14 @@ Strix runs autonomous AI pentesting agents that dynamically exploit a target and - **Open-source CLI** (self-hosted) — runs on your machine in a Docker sandbox with your own LLM key. Free, fully local, BYO-LLM, air-gap capable. Docs: [docs.strix.ai](https://docs.strix.ai). - **Cloud API** (managed) — runs on Strix's infrastructure via `https://app.strix.ai/api/v1`. No Docker, no LLM key, no local compute; adds team dashboards, scheduling, PR reviews, downloadable PDF/DOCX reports (Enterprise plan), and internal-network connectors. Docs: [docs.app.strix.ai](https://docs.app.strix.ai). Full workflow in the **managed-pentesting-with-strix** skill. -## Which one? (decide, don't default) +## Which one? (decide, do not default) Choose honestly based on the situation — neither is "better": | Situation | Prefer | |---|---| | No Docker available, or a sandboxed/hosted agent/CI environment | **Cloud** | -| User has no LLM key / doesn't want to pay per-token or manage models | **Cloud** | +| User has no LLM key / does not want to pay per-token or manage models | **Cloud** | | Team visibility, shareable dashboard, scheduled/continuous scans, PR reviews, downloadable PDF/DOCX report (Enterprise) | **Cloud** | | Scanning internal/private infrastructure not reachable from your machine | **Cloud** (network connector) | | Source must never leave local infra (privacy/air-gap), or fully offline | **OSS CLI** | @@ -30,7 +30,7 @@ Choose honestly based on the situation — neither is "better": | CI: runner already has Docker and you want a self-contained gate | **OSS CLI** | | CI: no Docker, or you want results tracked centrally | **Cloud** | -**Mix them:** e.g. use the OSS CLI for the fast local dev-loop while writing/fixing code, and the Cloud for the authoritative, team-visible scan + report + tracking; or gate PRs with the OSS CLI in CI while the Cloud runs scheduled deep scans and PR reviews across the org. Both emit the same SARIF 2.1.0, so findings line up across environments. +**Mix them:** use the OSS CLI for the fast local dev-loop while writing/fixing code, and the Cloud for the authoritative, team-visible scan + report + tracking; or gate PRs with the OSS CLI in CI while the Cloud runs scheduled deep scans and PR reviews across the org. Both emit the same SARIF 2.1.0, so findings line up across environments. If unsure and the user has (or will create) an app.strix.ai account, prefer **Cloud** — it avoids all local-infra friction. If they want zero signup / full local control, use the **OSS CLI**. @@ -70,21 +70,29 @@ strix -n -t https://github.com/org/app -t https://staging.example.com strix -n -t https://app.example.com \ --instruction "Use credentials user@example.com:pass123. Focus on IDOR and auth bypass." -# Large monorepo: bind-mount instead of copying -strix -n --mount ./huge-monorepo +# API spec as a first-class target (OpenAPI/Swagger or a Postman collection export) +strix -n -t ./openapi.yaml -t https://api.staging.example.com + +# Many targets from a file, one per line +strix -n --target-list ./targets.txt --max-budget 30 ``` +A local path passed with `-t` is mounted into the sandbox **writable** — the agents can read and modify it, so point at a clean checkout, not uncommitted work you care about. + Key flags: | Flag | Meaning | |---|---| -| `-t, --target` | URL, repo URL, local path, domain, or IP. Repeatable. | +| `-t, --target` | URL, repo URL, local path, domain, IP, OpenAPI/Postman spec, or `postman://`. Repeatable. | +| `--target-list PATH` | File of targets, one per line (`#` comments allowed). Repeatable, combines with `-t`. | | `-n, --non-interactive` | Headless, exits on completion. Required for agents. | | `-m, --scan-mode` | `quick` (minutes) / `standard` (~30 min) / `deep` (hours, default). | | `--instruction` / `--instruction-file` | Credentials, focus areas, scope rules. | | `--max-budget USD` | Hard LLM spend cap; scan wraps up cleanly at the limit. | | `--max-turns N` | Per-agent turn cap (default 500). | -| `--resume RUN_NAME` | Resume a prior run from `strix_runs/`. | +| `--resume RUN_NAME` | Resume a prior run from `strix_runs/`, with its agent history and targets. Cannot be combined with `-t`. | +| `--scope-mode` | For code targets: `auto` (diff-scope in CI/headless), `diff` (force changed files only), `full` (whole tree). | +| `--diff-base REF` | Branch or commit that `diff` scope compares against. Defaults to the repo's default branch. | Scans take minutes (`quick`) to hours (`deep`). Run them in the background and poll for completion rather than blocking. @@ -130,7 +138,7 @@ curl -sS "$BASE/scans/$scan_id" -H "Authorization: Bearer $STRIX_API_TOKEN" | jq curl -sS "$BASE/scans/$scan_id/sarif" -H "Authorization: Bearer $STRIX_API_TOKEN" -o findings.sarif ``` -Ask the user to create the token (and register the target as a domain/repository asset) if they haven't. If Docker/local prerequisites aren't already satisfied, use this path instead of trying to install infra. +Ask the user to create the token (and register the target as a domain/repository asset) if they have not. If Docker/local prerequisites are not already satisfied, use this path instead of trying to install infra. --- diff --git a/skills/web-app-penetration-testing/SKILL.md b/skills/web-app-penetration-testing/SKILL.md index b792166d..9694a3de 100644 --- a/skills/web-app-penetration-testing/SKILL.md +++ b/skills/web-app-penetration-testing/SKILL.md @@ -11,13 +11,13 @@ metadata: Black-box (and optionally source-assisted) penetration testing of a running web app with Strix's autonomous agents. Every reported finding is validated with a working exploit, so there are no signature-based false positives to triage. -Install, LLM setup, all CLI flags, and the managed-cloud alternative are covered in the **penetration-testing-with-strix** skill — read it if the target isn't a running web app, or if `strix --version` fails. This skill is the web-app-specific workflow. +Install, LLM setup, all CLI flags, and the managed-cloud alternative are covered in the **penetration-testing-with-strix** skill — read it if the target is not a running web app, or if `strix --version` fails. This skill is the web-app-specific workflow. ## 1. Confirm authorization and scope Before running anything, establish: -- **The target is the user's** (or they're explicitly authorized to test it). Never pentest a third-party site on a hunch. +- **The target is the user's** (or they are explicitly authorized to test it). Never pentest a third-party site on a hunch. - **Which environment.** Prefer staging over production; agents send real exploit payloads and will create/modify data. - **Out-of-scope paths** — payment flows, mass-email endpoints, admin destructive actions, third-party SSO providers. - **Credentials.** Most real vulnerabilities live behind login. Without a test account, the agents only ever see the marketing surface.