find-security-vulnerabilities-in-code

A code-security review workflow that reads a repository, traces how data and permissions work, and tries to exploit weaknesses in a sandbox. It reports issues with working proof-of-concept demonstrations.

In plain words
What is it for?
Use it to test a local repository, GitHub repository, monorepo service, running application, or only the code changed on a branch.
Why use it?
It helps separate exploitable security problems from warnings that only look suspicious to a pattern-based scanner.

Skill for Claude CodeCodex

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add skills/usestrix/strix/find-security-vulnerabilities-in-code
Any agent
npx skills add usestrix/strix --skill find-security-vulnerabilities-in-code
Clone the repo
git clone --depth 1 https://github.com/usestrix/strix

Made for: Claude Code, Codex.

Per session 129 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 942 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00129 $0.00942
Opus 5 $0.00064 $0.00471
Sonnet 5 $0.00026 $0.00188
Haiku 4.5 $0.00013 $0.00094

Measured yesterday against content hash 2633d6b57540, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

find-security-vulnerabilities-in-code scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

skills/find-security-vulnerabilities-in-code/SKILL.md · 63 lines

How it starts

The opening of the file, as written. The whole thing — 63 lines — stays where its author put it; the contents beside it link to each section on GitHub.

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.

Run it

# Local working tree
strix -n -t ./ --scan-mode standard --max-budget 15

# A GitHub repo directly
strix -n -t https://github.com/org/app --max-budget 15

# 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.
  2. Scope the review. Point at the risky subtree and say what matters:
    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 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 full file on GitHub · 63 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. yesterday First seen · 63 lines · 129 tokens per session scan A 2633d6b57540

Subscribe to this mod's changes

find-security-vulnerabilities-in-code is a skill published in the GitHub repository usestrix/strix (59,426 stars, last pushed 3d ago), licensed Apache-2.0. It adds 129 tokens to every session and 942 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.