Find security vulnerabilities in a codebase or repository with Strix — a white-box AI security review that reads your source, reasons about the actual data flow and authorization model, then exploits what it finds in a live sandbox so every reported issue has a working proof-of-concept instead of a

Find security vulnerabilities in code White box security review with Strix: the agents read the source to build a model of routes, sinks, and authorization checks, then attempt real exploitation. Findings come with a proof of concept, so the output is a short list of proven issues rather than the hundreds of "potential" hits a pattern matching scanner produces. Install, LLM setup, all flags, and the managed cloud path are in the penetration testing with strix skill. 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 ). Run it 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. 2. Scope the review. Point at the risky subtree and say what matters: 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 For diff scoped review of a branch or PR (and blocking merges on findings), use ci security scanning with strix — it covers diff scoping, PR comments, and SARIF upload to GitHub code scanning. The managed platform can also review PRs directly via API ( managed pentesting with strix ). Read the results In strix runs/<run / : penetration test report.md (start here), vulnerabilities/ .md (one per finding, with PoC and remediation), vulnerabilities.json / .csv , findings.sarif (upload to code scanning), run.json . Before reporting to the user, open each finding and check the PoC actually demonstrates impact. Report file and line alongside the exploit so the fix is obvious. Exit 0 means nothing exploitable was proven in what was analyzed — not that the codebase is clean. Check run.json status and cost against max budget , and note which paths went unreviewed if the run was capped. 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 cannot find. Fix and verify Hand results to fix security vulnerabilities with strix : patch the root cause (the shared authorization helper, not the one route), then re run Strix to prove the exploit no longer works.

find-security-vulnerabilities-in-code