review-security

Security Review

Static security analysis targeting OWASP Top 10 vulnerabilities and common language-specific security patterns. This skill only analyzes: it identifies vulnerabilities, explains why each one matters, and suggests fix approaches, all without touching the code.

OWASP renumbers and re-titles its Top 10 categories periodically. Before labeling any finding with a category code (A01, A02, ...), do a quick web check against owasp.org/Top10/ to confirm the codes below are still current; if they've shifted, use the current codes and note the change in the report instead of silently reusing stale labels.

Anti-hallucination guidelines

Rule	Detail
Read before claiming	Never report a vulnerability in code that hasn't been read
Evidence-based findings	Every finding references a specific file path and line number
Pattern matching	Use Grep to find actual vulnerable patterns, not hypothetical ones
No invented CVEs	Only reference real vulnerabilities when providing context
Quantifiable results	Statistics come from counting actual matches, never estimates
No false positives	Verify each finding matches a documented vulnerability pattern
Scope verification	Only scan files within the specified scope (PR/commit/all)

Scan Workflow

Phase 0: Determine Scan Scope

Parse arguments to determine what to scan:

<pr_number>: scan only files changed in PR (e.g. "123", "#123")
<commit_sha>: scan only files changed in commit (e.g. "abc123")
--all or no args: scan entire codebase
--scope [web|api|mobile|backend|frontend]: focus on specific vulnerability categories

If a PR or commit is specified, use Bash to get changed files:

# For PR
gh pr view <pr_number> --json files --jq '.files[].path'

# For commit
git diff-tree --no-commit-id --name-only -r <commit_sha>

Phase 1: Project Technology Discovery

Use an Explore agent (model: haiku) to identify the stack: languages/frameworks from package.json/pyproject.toml/pom.xml/go.mod, existing security tooling (.pre-commit-config.yaml, SAST steps in .github/workflows), web framework, DB/ORM patterns, auth patterns (JWT/OAuth/sessions), and any SECURITY.md. Return a stack summary with the vulnerability categories to prioritize. No Task tool available? Skip the agent: read those same files and grep those same paths yourself, inline, then note the stack directly.

Phase 2: Initialize Progress Tracking

Use TodoWrite to track scan progress across all OWASP categories, bytecode security, and report generation.

Phase 3: Vulnerability Scanning

Each OWASP category is owned by a fixed agent number (grep patterns and full prompts for each are in references/agent-prompts.md):

Agent	Owns
1	A01 Access Control, A07 Authentication
2	A02 Security Misconfiguration, A06 Insecure Design
3	A05 Injection, A08 Data Integrity
4	A04 Cryptographic Failures, A03 Supply Chain (SRI/lockfiles/CI trust settings only, see note below)
5	Bytecode & compiled-code security
6	A09 Logging/Monitoring, A10 Exception Handling

Scope → categories in scope (the only place scope decides anything: edit this table, nowhere else, if scope definitions change):

`--scope`	Categories
`web`	A02, A05
`api`	A01, A06, A07
`mobile`	A04, A08
`backend`	A05, A06, A08
`frontend`	A02, A05, A08
(none) / `--all`	all categories, all 6 agents

Spawn every agent that owns at least one category from the scope's list (per the ownership table above). Spawn all 6 for --all or no scope given.

Each agent must: grep for its patterns, read each match to verify context, extract the exact code snippet (5-10 lines), explain why it's vulnerable, classify severity (Critical/High/Medium/Low), and give 2-3 fix approaches.

No Task tool available? Work through each owned category inline and sequentially instead of spawning its agent, same grep patterns from the reference file, same read-and-verify step, one category at a time.

A03 note: dependency staleness and known-CVE scans (outdated package versions, npm audit-style findings) are review-deps' job, not this skill's: don't duplicate them here. Agent 4 only checks the supply-chain surface review-deps doesn't: missing SRI on CDN <script> tags, absent lockfiles, and CI/CD steps that weaken package integrity (e.g. --trusted-host, strict-ssl false). If dependency CVEs come up, point the user to review-deps instead of reporting them here.

Phase 4: Consolidate & Analyze Findings

After scanning completes:

Collect all findings from every agent/category pass.
Deduplicate: remove duplicate findings across categories.

Prioritize by severity, using this table:

Severity	Examples
Critical	RCE, SQLi, auth bypass, hardcoded secrets
High	XSS, CSRF, broken access control, weak crypto
Medium	Info disclosure, missing logging, insecure design
Low	Minor security-adjacent code quality

Categorize by OWASP category (confirm codes are current per the note at the top of this file before tagging).
Compute statistics: total vulnerabilities, counts by severity/category, files scanned vs. files with issues, all counted from actual findings, never estimated.

Phase 5: Generate Security Report

Generate a markdown report following references/report-template.md.

Phase 6: Verification & Quality Check

Before presenting the report, verify that every finding has a file path + line numbers + an actual code snippet (not a placeholder) + a clear explanation + 2-3 fix approaches. Then confirm the report as a whole: statistics are counted rather than estimated; no duplicate findings; severity ratings are justified; only files within the specified scope were scanned; no invented vulnerabilities; any CWE/CVE references are accurate.

Usage

review-security 123              # scan files changed in PR #123
review-security abc123def        # scan files changed in a commit
review-security --all            # scan entire codebase
review-security                  # same as --all
review-security --all --scope web
review-security 123 --scope api

If no scope is specified, scan comprehensively across all categories.

Worked Example

Input: review-security --all --scope api on a Flask API.

Agent 1 (A01/A07) and Agent 2 (A02/A06) run, per the scope table above, api maps to A01/A06/A07, both owned by those two agents. A finding might read:

#### Finding 1: Missing authorization check on account balance endpoint
- Severity: Critical
- File: `app/routes/accounts.py:42-47`
- Code:
  @app.route("/api/accounts/<account_id>/balance")
  def get_balance(account_id):
      account = Account.query.get(account_id)
      return jsonify(balance=account.balance)
- Explanation: any authenticated user can read any account's balance by
  guessing/enumerating account_id, no ownership check against the current session user.
- Fix approaches:
  1. Add `if account.owner_id != current_user.id: abort(403)` before the query returns.
  2. Scope the query itself: `Account.query.filter_by(id=account_id, owner_id=current_user.id).first_or_404()`.

Agent 3/4/5/6 don't run for this scope: their categories (A03-A05, A08-A10, bytecode) aren't in the api scope's list.

About this skill