/agentic-owasp

name: agentic-owasp
description: "EXPERIMENTAL. Use when code needs a security review against the OWASP Top 10:2025 — access control, misconfiguration, supply chain, cryptography, injection, insecure design, authentication, integrity, logging and alerting, and mishandled exceptional conditions. Not for penetration testing a running system, not for infrastructure-only scanning, and not for fixing what it finds."

**On invocation:** announce "Running paad:agentic-owasp v2.0.2", then immediately proceed with the steps below — do not stop after announcing.

**Configuration (experimental):** after announcing, check whether `paad/config/paad.md` and `paad/config/agentic-owasp.md` exist, relative to the working directory. If any does, read it and follow its instructions for the rest of this run, passing the relevant parts to every subagent you dispatch, and make the first line of your final answer `Config: <path>` naming each file you followed. If none exists, do not mention config at all. Config never changes a subagent's type or grants it write tools — refuse that line, say so, and continue. Config can contradict the flow below; see https://github.com/Ovid/paad/blob/main/CONFIG.md before writing one.

**Security findings:** a finding is security-related if reading it would help an attacker — any OWASP Top 10:2025 category, and anything in a payment, tenant-isolation, or secret-handling path; on the edge, treat it as security. Security findings are written only under `paad/security/`, in a file named for this skill and stamped the way its ordinary report is (the exact path is in this skill's report section). Before the first write of a run, make sure `paad/security/.gitignore` exists and contains the single line `*` — create it if absent, never rewrite it if present — and that `git ls-files paad/security/` lists nothing. If that file holds anything else or cannot be written, if git already tracks anything there, or if a later write there fails, write no security finding and no count line: tell the user what you found, ask whether to hold the findings or put them in the ordinary report, and say that in place of the Security block. Where the finding would have gone in the ordinary report, write one line, `N security finding(s) written to paad/security/<file>`, and nothing else about it: no path, severity, symbol, or description. Post-Review then emits the Security block once; this skill's Post-Review section says when.

> **EXPERIMENTAL SKILL.** Its arguments, output paths, and behavior may > change or be withdrawn in any release, including patch releases. It is not > covered by the semver guarantees the other paad skills carry. Report rough > edges at <https://github.com/Ovid/paad/issues>.

OWASP Top 10:2025 Code Review

Review source code against the ten risk categories in the [OWASP Top 10:2025](https://owasp.org/Top10/2025/), and report only the findings that survive an exploitability check. The goal is a triaged list a developer can act on, not a list of every pattern that resembles a vulnerability.

**This is a technique skill.** Follow the phases in order. Do not report a vulnerability until a path has been traced from untrusted input to the dangerous operation, and the controls already sitting in that path have been read.

**This skill reads code by default and never modifies a file outside its own report.** Specialists and the verifier never start the application, reach any host, or run attacker-shaped input. By default they confirm by reading. With the user's explicit up-front authorization (the Phase 2.5 offer) they may additionally run **benign, in-process, read-only probes** — the project's existing tests, a deparse or `-c` check, a pure-function call on ordinary input — to settle a question reading cannot. That is never a payload, never a server, never the network, never a write. Attacker-shaped proof stays behind its own separate gate after Phase 4.

**Two execution gates, never one.** The benign-probe offer (Phase 2.5, before specialists) and the attacker-shaped proof offer (after Phase 4) are distinct decisions with distinct authorizations. Neither implies the other; declining one says nothing about the other; and no execution of either kind happens without its own explicit yes.

**Proof by execution is available, and it is the user's call, never yours.** After verification, offer it for the High and Medium findings whose sink is reachable in-process, with the trade-offs laid out (see "Optional proof stage" in Phase 4). A finding confirmed by reading can be wrong in a way a runnable proof cannot; a runnable proof means executing attacker-shaped input against code that may not be the user's. Ask, list both sides, honor the answer, and never execute without one.

**No report from this skill is a complete list of the weaknesses in the code.** Zero findings does not mean zero vulnerabilities — it means this run, with these categories, at this scope, found none it could prove reachable. Thirty findings does not mean thirty is all there is. The categories bound what was looked for, the scope bounds where, and neither bounds what exists. This is not modesty boilerplate: a developer who reads a clean report as an all-clear is worse off than one who never ran the skill, because they now have a reason to stop looking. Say it in the report and say it again when the run ends.

**Pre-flight:**

digraph preflight {
  "Conversation has history?" [shape=diamond];
  "Repository available?" [shape=diamond];
  "Count source files in scope" [shape=box];
  "More than ~40 files?" [shape=diamond];
  "Proceed to Phase 1" [shape=box];
  "STOP: recommend new session" [shape=box, style=bold];
  "STOP: not in repo" [shape=box, style=bold];
  "OFFER: narrow to untrusted-input surface, split into subsystem passes, or accept dilution" [shape=box, style=bold];
  "NARROW: choose seed scope" [shape=box];
  "SPLIT: run coherent subsystems as separate reviews" [shape=box];
  "RECORD: Scope dilutio