Guide · Agent skill
How to find security vulnerabilities in code with Strix (agent skill)
Updated · written with AI from the project's own documentation and checked against our catalogue data
This guide explains the find-security-vulnerabilities-in-code agent skill, which lets an AI agent run Strix against your source code or repository. It is for developers and teams who want a deeper review than a linter gives and who want each reported issue backed by a working proof-of-concept. By the end you will know how to install the skill, trigger it with a plain request, scope the review, and read the results.
Find Security Vulnerabilities in Codeusestrix/strix · Apache-2.0 Download the skill Quick start
- 1Check prerequisites. Install the Strix CLI and Docker, and set up an LLM API key or Strix cloud account as described in the penetration-testing-with-strix skill.
- 2Download and unzip the skill. Download the ZIP from this page and unzip it into ~/.claude/skills/ or a project's .claude/skills/ folder.
- 3Or upload it in the Claude apps. Under Settings → Capabilities → Skills, upload the ZIP.
- 4Make a clean checkout. Check out the code you own in a clean state, because the mounted folder is writable.
- 5Ask for a security review. Request a security scan, review, or audit of your code, repo, or pull request in plain language.
- 6Scope and add a live target. Point at the risky service and add a running app URL so findings can be confirmed.
- 7Read and verify findings. Open penetration_test_report.md and each vulnerability file, check the PoC shows impact, and fix root causes.
What is an agent skill, and what does this one make the agent do?
An agent skill is a folder containing a SKILL.md file that tells an AI agent when and how to perform a task. This skill is named find-security-vulnerabilities-in-code and is published under the Apache-2.0 licence by usestrix/strix.
Once installed, the agent can run Strix, an open-source AI security tool, against your source code or repository. Strix is a white-box review: the agents read the code to map routes, risky operations and authorization checks, then attempt to actually exploit suspected bugs in a live sandbox. The output is a short list of issues that were exploited, each with a proof-of-concept, instead of a long list of unverified warnings.
- Covers injection, XSS, SSRF, broken access control and IDOR, insecure deserialization, secrets in code, unsafe dependencies, and business-logic flaws.
- Reports include file and line references alongside the exploit.
What do you need before you install the skill?
The skill depends on other pieces. Check these first:
- Strix CLI installed.
- Docker, for the local sandbox run.
- An LLM API key or model configuration for Strix, or a Strix cloud account for the managed path. LLM setup is covered by the penetration-testing-with-strix skill.
How do you install the skill?
Download the ZIP for this skill from the page you are reading, then unzip it. Put the resulting folder in one of these locations:
- Personal skills: ~/.claude/skills/
- Project skills: a project's .claude/skills/ folder
- Claude apps: upload the ZIP under Settings → Capabilities → Skills
How do you trigger the skill with a natural request?
You do not need a command name. Ask the agent in plain language to security-scan, security-review, or audit your code, repo, or pull request for vulnerabilities. The skill's description lists these trigger phrases, so the agent loads it when your request matches.
- Security-scan this repo for vulnerabilities.
- Do a security review of the checkout service in ./services/checkout.
- Audit the auth code in this branch for broken access control.
What commands does the skill run?
The skill runs the Strix CLI. A local working tree is mounted into the sandbox writable, so the agents can modify it, so run against a clean checkout. A GitHub repo can be passed directly. To review only what a branch changed, use diff scoping.
- Use --max-budget to cap cost.
- Use --scope-mode diff with --diff-base origin/main to review only changes on a branch.
- Add a running instance of the app with a second -t target so the agents can confirm exploitability against live behavior.
strix -n -t ./ --scan-mode standard --max-budget 15
strix -n -t https://github.com/org/app --max-budget 15
strix -n -t ./services/checkout --max-budget 20
strix -n -t ./ --scope-mode diff --diff-base origin/main --max-budget 10How do you get better results by scoping the review?
Point the review at the risky subtree and say what matters. The agents cannot reliably infer your tenancy model, trust boundaries, or which inputs an attacker controls, so state them in the instruction. If no running instance of the app is available, describe static-only findings as unconfirmed.
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."How do you read the results?
Results are written to strix_runs/<run>/. Start with the penetration test report, then open each individual finding. Check that each proof-of-concept actually demonstrates impact before you act on it. Exit code 0 means nothing exploitable was proven in what was analyzed, not that the codebase is clean. Check run.json for status and cost against your budget, and note any paths left unreviewed if the run was capped.
- penetration_test_report.md: start here.
- vulnerabilities/*.md: one file per finding, with PoC and remediation.
- vulnerabilities.json and vulnerabilities.csv.
- findings.sarif: can be uploaded to code scanning.
- run.json: status and cost.
What are the safety notes for scripts and network use?
This skill runs scripts and uses the network. Strix's agents may modify the mounted folder and attempt real exploitation, so only run it against code you own or have permission to test. Use a clean checkout and keep the run inside your budget.
- Only test code you own or are authorised to test.
- Work on a clean checkout, since the mounted folder is writable.
- Keep a dependency scanner and secret scanner in place alongside this skill.
What tips help the review go well?
Scope the review to the service that matters rather than the whole monorepo, and use diff scoping for branch reviews on large repositories. For fixes, patch the root cause, such as a shared authorization helper, then re-run Strix to confirm the exploit no longer works. The related skills fix-security-vulnerabilities-with-strix and ci-security-scanning-with-strix cover those steps.
- Give the agents a running instance of the app to validate findings.
- Describe tenancy and trust boundaries in your instruction.
- Use the managed platform, via strix cloud, if you do not want Docker or a local LLM key; the managed-pentesting-with-strix skill covers it.
What people use it for
- Deep review of a single service or monorepo subtree before a release.
- Checking authorization and IDOR logic in a multi-tenant app.
- Reviewing a branch's changes with diff scoping to find new injection or business-logic bugs.
- Preparing a codebase for an external audit by pre-checking authorization and injection issues.
Frequently asked questions
How do I install the find security vulnerabilities in code skill?
Download the ZIP from this page and unzip it into ~/.claude/skills/ for personal use or a project's .claude/skills/ folder for one project. In the Claude apps, you can instead upload the ZIP under Settings → Capabilities → Skills.
What do I need to run it?
You need the Strix CLI installed and Docker for the local sandbox run. You also need an LLM API key or model configuration for Strix, or a Strix cloud account for the managed path.
Is this skill free?
The skill is licensed under Apache-2.0. The source does not state pricing for LLM usage or the managed cloud, so check those separately; runs can be costly, so use --max-budget to cap spend.
How is this different from a linter or static analysis scanner?
Strix reads the code, then tries to exploit suspected bugs in a sandbox, so each reported issue has a proof-of-concept. A pattern-matching scanner typically produces unverified warnings instead.
Why did the scan finish without finding anything?
Exit code 0 means nothing exploitable was proven in what was analyzed, not that the code is clean. Check run.json for status, and note whether the run was capped by budget before the whole tree was reviewed.
Should I use this instead of a dependency or secret scanner?
No. For known-CVE dependencies and committed secrets, dependency and secret scanners cover more completely, so keep them alongside this skill.
New agent skills, repos and AI tools — every week
The best new skills and open-source projects, the fastest-growing repos, and one free prompt. Five minutes to read. Unsubscribe anytime.
Our verdict
Use this skill if you want exploit-validated findings for logic, authorization and injection bugs in code you own, and you can supply Docker, an LLM setup and a budget. Pick a dependency scanner or secret scanner instead when your main concern is known-CVE packages or leaked credentials, or when you need a fast, cheap check of a large repository.
Download the skill