utkusen/sast-skills: LLM SAST Skills for Finding Vulnerabilities in Web and Mobile Apps

What utkusen/sast-skills solves, and for whom

Static application security testing normally means installing a scanner, wiring it into a build, and then arguing with its false positives. utkusen/sast-skills takes a different route. It is a set of agent skills: Markdown instructions that an LLM coding assistant reads and follows. The README describes the result as turning your assistant into "a fully functional SAST scanner" and states that no third-party tools are required.

The target user is a developer or security engineer who already has Claude Code, Codex, Opencode, Cursor or another assistant that supports agent skills, and who wants a vulnerability pass over a codebase without standing up new infrastructure. The README recommends Claude Code with the Opus model and adds that if cost is a concern, any IDE and model you trust will do. That sentence is the honest centre of the project: the quality of the scan is bounded by the model you point at it.

The scope is web and mobile applications. The skill list covers SQL injection, GraphQL injection, XSS, RCE, SSRF, IDOR, XXE, SSTI, JWT weaknesses, missing authentication and broken function-level authorization, path traversal, insecure file upload, and business logic flaws. That list is a useful map of what the toolkit will and will not look for. Memory-safety bugs in C or C++, cryptographic protocol design, and supply chain issues are not on it.

The three-step pipeline: analysis, parallel detection, report

The mechanism is unusual for a security tool because there is no binary and no server. Orchestration lives in `CLAUDE.md` for Claude Code or `AGENTS.md` for Opencode and other IDEs. The README states that this entry point file "orchestrates the entire assessment workflow automatically" and that it skips any step whose output files already exist, which is what makes re-running safe after fixes.

Step one is a single skill, `sast-analysis`, which maps the technology stack, architecture, entry points, data flows and trust boundaries, writing to `sast/architecture.md`. Step two runs all 13 vulnerability detection skills in parallel as subagents. Each of those follows a two-phase approach: a recon or discovery phase to find candidate sections, then a verification phase to confirm exploitability, with results in `sast/*-results.md`. Step three is `sast-report`, which consolidates everything into `sast/final-report.md`, ranked by severity with remediation guidance and, per the README, dynamic test instructions.

The two-phase design is the part worth paying attention to. Asking a model to find vulnerabilities produces a long list of plausible-looking code. Asking it to then verify exploitability is an attempt to filter that list before it reaches the report. Whether it works depends on the model, and the README does not publish precision or recall figures, so treat the verification phase as a prompt-level mitigation rather than a measured one. The architecture file also matters more than it looks: it is the shared context that later skills read, so if `sast/architecture.md` misreads the stack, every downstream finding inherits the mistake.

Installing sast-skills and running a first scan

Installation is a file copy. The README instructs you to copy your project into the `sast-files` folder and then open `sast-files` as your workspace in your AI coding assistant.

cp -r /path/to/your/project sast-files/

After that copy, `sast-files` contains both your code and the skill definitions, and that combined directory is what the assistant opens. The README carries one warning that is easy to miss and will silently degrade the run: if your project already contains a `CLAUDE.md` or `AGENTS.md` file, remove it before running the assessment, because it will conflict with the orchestration file the toolkit provides. Check for both names, including any you added for unrelated reasons.

With the workspace open, you trigger the scan in plain language. The README gives two phrasings:

Run vulnerability scan

Find vulnerabilities in this codebase

What you should see is a `sast/` folder appear in the project root. It fills with `sast/architecture.md` first, then per-class files such as `sast/*-results.md`, and finally `sast/final-report.md`. Because the entry point skips completed steps, a second run after you patch a bug will reuse the existing architecture file and existing results rather than starting over. If you want a clean pass, the README's own logic implies you must remove the stale files in `sast/` yourself; it does not document a reset flag.

Where sast-skills breaks down

The first limitation is cost. Every skill is a model call, 13 detection skills run as subagents, and each one does recon and then verification. On a large repository that is a lot of tokens, and the README's own fallback advice, to use a cheaper model if cost is a concern, is an admission that scan quality and spend are the same dial. A small team scanning a monorepo nightly will feel this immediately.

The second is reproducibility. A conventional SAST tool returns the same findings for the same commit. An LLM-driven scan does not, and the README makes no determinism claim. That rules the toolkit out as a merge gate: you cannot fail a pull request on a result that may not appear next run.

The third is the absence of a documented baseline. There is no ignore file, no suppression syntax, no severity threshold configuration mentioned in the README. If `sast-businesslogic` flags a pattern your team has already accepted, the only documented response is to read the finding in `sast/*-results.md` and move on. That is fine for a one-off review and awkward for a workflow.

Finally, the conflict warning cuts both ways. Removing your project's `AGENTS.md` is correct for this tool, but if that file carries build instructions or conventions your assistant relies on, you have just changed how the assistant behaves for the rest of the session. Copy the file aside before deleting it.

How this differs from Semgrep and other pattern-based scanners

Semgrep is the obvious comparison, because it is also free to start with and also aimed at source code. The difference is the engine. Semgrep matches rules written against a parsed syntax tree, so a finding is traceable to a rule and a line, and the same input gives the same output. utkusen/sast-skills has no rules. It has prompts. The `sast-analysis` skill builds a model of your architecture, and the detection skills reason over that model.

That buys coverage of classes that rules handle badly. Business logic flaws are the clearest case: price manipulation, workflow bypass and race conditions depend on intent, and the README lists them as a skill precisely because no pattern expresses them well. A rule engine will also miss an authorization gap that only exists because of how two services call each other, which is the kind of thing `sast-missingauth` is meant to catch by reading the data flow map.

The trade is auditability. When Semgrep reports an issue you can read the rule, argue with it, and disable it for one path. When this toolkit reports an issue you get prose in `sast/*-results.md` with proof and remediation, and your only lever is the prompt. Teams under a compliance regime that wants a documented rule set will find that unsatisfying. Teams that want a second opinion on a codebase before a launch will find it cheap to try.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-04-08. That is roughly five months before today, so this is not a project with a fast-moving commit history, and the README does not describe a versioning scheme. There are no releases retrieved, which means there is no changelog to read before upgrading. In practice you upgrade by pulling the latest `sast-files/` contents and re-copying your project in, and the cost of that is re-running the scan, since the skills are the product and there is nothing else to install.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence and it is worth noting that MIT offers no warranty, so a missed vulnerability in `sast/final-report.md` is not something the licence covers. None of this is legal advice; if you redistribute a modified version inside a product, have counsel read the LICENSE file in the repository root.

One practical upgrade note: because the orchestration files are named `CLAUDE.md` and `AGENTS.md`, an update can change how your assistant behaves in that workspace even when you did not intend to change your assistant's configuration. Diff those two files before you overwrite them.

Editorial conclusion

Adopt utkusen/sast-skills if you already pay for an LLM coding assistant and want a second pass over a small to medium web or mobile codebase, with findings written to sast/final-report.md for a human to triage. Do not adopt it if you need a gate in CI, deterministic results, or coverage of a language whose vulnerability classes are not among the 13 listed skills. Before trusting any finding, verify three things: that your project's own CLAUDE.md or AGENTS.md was removed, that sast/architecture.md describes the stack you actually run, and that each reported issue in sast/*-results.md points at a reachable entry point rather than a pattern match.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. utkusen/sast-skills on GitHub