Test against the OWASP Top 10
The OWASP Top 10 is a taxonomy of risk categories, not a test suite — "OWASP Top 10 testing" means exercising each category against the real application and reporting what's actually exploitable. Strix's agents do the exploitation; this skill covers running it category-by-category and reporting coverage honestly.
Use the current edition: OWASP Top 10:2025 (8th installment, superseding 2021). Ask the user before targeting an older edition — some compliance checklists still reference 2021, and a report labelled with the wrong edition is misleading. Key differences from 2021: SSRF is folded into A01, A03 Software Supply Chain Failures expands the old "Vulnerable and Outdated Components", and A10 Mishandling of Exceptional Conditions is new; A02 Security Misconfiguration moved 5→2.
Install, LLM setup, and the managed-cloud alternative: penetration-testing-with-strix. For a run with no Docker and no LLM key, the same binary drives the managed platform: strix cloud login, then strix cloud scans start ... (details in managed-pentesting-with-strix).
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.
For APIs, run the same exercise against the OWASP API Security Top 10 (2023) — API1 BOLA, API3 Broken Object Property Level Authorization (2019's excessive data exposure + mass assignment merged), API5 broken function-level authorization — using the api-security-testing skill.
Run it
Maximum category coverage comes from giving the agents both the source and a running instance, plus credentials at two privilege levels:
--scan-mode deepmatters here: systematically walking ten categories is not a quick scan.- Without a second account, A01 results are structurally incomplete — say so in the report rather than leaving it implied.
- Need an auditor-facing PDF? Run it through the managed platform and pull the technical report (managed-pentesting-with-strix).
Report honestly
From strix_runs/<run>/, 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.
Then fix and re-test
Remediate with fix-security-vulnerabilities-with-strix and re-run to prove each exploit is closed. For ongoing coverage as the app changes, gate pull requests using ci-security-scanning-with-strix.


