security-review

SKILL.md

Security Review

An AI-powered security scanner that reasons about your codebase the way a human security
researcher would — tracing data flows, understanding component interactions, and catching
vulnerabilities that pattern-matching tools miss.

When to Use This Skill

Use this skill when the request involves:

Scanning a codebase or file for security vulnerabilities

Running a security review or vulnerability check

Checking for SQL injection, XSS, command injection, or other injection flaws

Finding exposed API keys, hardcoded secrets, or credentials in code

Auditing dependencies for known CVEs

Reviewing authentication, authorization, or access control logic

Detecting insecure cryptography or weak randomness

Performing a data flow analysis to trace user input to dangerous sinks

Any request phrasing like "is my code secure?", "scan this file", or "check my repo for vulnerabilities"

Running /security-review or /security-review <path>

How This Skill Works

Unlike traditional static analysis tools that match patterns, this skill:

Reads code like a security researcher — understanding context, intent, and data flow

Traces across files — following how user input moves through your application

Self-verifies findings — re-examines each result to filter false positives

Assigns severity ratings — CRITICAL / HIGH / MEDIUM / LOW / INFO

Proposes targeted patches — every finding includes a concrete fix

Requires human approval — nothing is auto-applied; you always review first

Execution Workflow

Follow these steps in order every time:

Step 1 — Scope Resolution

Determine what to scan:

If a path was provided (/security-review src/auth/), scan only that scope

If no path given, scan the entire project starting from the root

Identify the language(s) and framework(s) in use (check package.json, requirements.txt,
go.mod, Cargo.toml, pom.xml, Gemfile, composer.json, etc.)

Read references/language-patterns.md to load language-specific vulnerability patterns

Step 2 — Dependency Audit

Before scanning source code, audit dependencies first (fast wins):

Node.js: Check package.json + package-lock.json for known vulnerable packages

Python: Check requirements.txt / pyproject.toml / Pipfile

Java: Check pom.xml / build.gradle

Ruby: Check Gemfile.lock

Rust: Check Cargo.toml

Go: Check go.sum

Flag packages with known CVEs, deprecated crypto libs, or suspiciously old pinned versions

Read references/vulnerable-packages.md for a curated watchlist

Step 3 — Secrets & Exposure Scan

Scan ALL files (including config, env, CI/CD, Dockerfiles, IaC) for:

Hardcoded API keys, tokens, passwords, private keys

.env files accidentally committed

Secrets in comments or debug logs

Cloud credentials (AWS, GCP, Azure, Stripe, Twilio, etc.)

Database connection strings with credentials embedded

Read references/secret-patterns.md for regex patterns and entropy heuristics to apply

Step 4 — Vulnerability Deep Scan

This is the core scan. Reason about the code — don't just pattern-match.
Read references/vuln-categories.md for full details on each category.

Injection Flaws

SQL Injection: raw queries with string interpolation, ORM misuse, second-order SQLi

XSS: unescaped output, dangerouslySetInnerHTML, innerHTML, template injection

Command Injection: exec/spawn/system with user input

LDAP, XPath, Header, Log injection

Authentication & Access Control

Missing authentication on sensitive endpoints

Broken object-level authorization (BOLA/IDOR)

JWT weaknesses (alg:none, weak secrets, no expiry validation)

Session fixation, missing CSRF protection

Privilege escalation paths

Mass assignment / parameter pollution

Data Handling

Sensitive data in logs, error messages, or API responses

Missing encryption at rest or in transit

Insecure deserialization

Path traversal / directory traversal

XXE (XML External Entity) processing

SSRF (Server-Side Request Forgery)

Cryptography

Use of MD5, SHA1, DES for security purposes

Hardcoded IVs or salts

Weak random number generation (Math.random() for tokens)

Missing TLS certificate validation

Business Logic

Race conditions (TOCTOU)

Integer overflow in financial calculations

Missing rate limiting on sensitive endpoints

Predictable resource identifiers

Step 5 — Cross-File Data Flow Analysis

After the per-file scan, perform a holistic review:

Trace user-controlled input from entry points (HTTP params, headers, body, file uploads)
all the way to sinks (DB queries, exec calls, HTML output, file writes)

Identify vulnerabilities that only appear when looking at multiple files together

Check for insecure trust boundaries between services or modules

Step 6 — Self-Verification Pass

For EACH finding:

Re-read the relevant code with fresh eyes

Ask: "Is this actually exploitable, or is there sanitization I missed?"

Check if a framework or middleware already handles this upstream

Downgrade or discard findings that aren't genuine vulnerabilities

Assign final severity: CRITICAL / HIGH / MEDIUM / LOW / INFO

Step 7 — Generate Security Report

Output the full report in the format defined in references/report-format.md.

Step 8 — Propose Patches

For every CRITICAL and HIGH finding, generate a concrete patch:

Show the vulnerable code (before)

Show the fixed code (after)

Explain what changed and why

Preserve the original code style, variable names, and structure

Add a comment explaining the fix inline

Explicitly state: "Review each patch before applying. Nothing has been changed yet."

Severity Guide

Severity
Meaning
Example

🔴 CRITICAL
Immediate exploitation risk, data breach likely
SQLi, RCE, auth bypass

🟠 HIGH
Serious vulnerability, exploit path exists
XSS, IDOR, hardcoded secrets

🟡 MEDIUM
Exploitable with conditions or chaining
CSRF, open redirect, weak crypto

🔵 LOW
Best practice violation, low direct risk
Verbose errors, missing headers

⚪ INFO
Observation worth noting, not a vulnerability
Outdated dependency (no CVE)

Output Rules

Always produce a findings summary table first (counts by severity)

Never auto-apply any patch — present patches for human review only

Always include a confidence rating per finding (High / Medium / Low)

Group findings by category, not by file

Be specific — include file path, line number, and the exact vulnerable code snippet

Explain the risk in plain English — what could an attacker do with this?

If the codebase is clean, say so clearly: "No vulnerabilities found" with what was scanned

Reference Files

For detailed detection guidance, load the following reference files as needed:

references/vuln-categories.md — Deep reference for every vulnerability category with detection signals, safe patterns, and escalation checkers

Search patterns: SQL injection, XSS, command injection, SSRF, BOLA, IDOR, JWT, CSRF, secrets, cryptography, race condition, path traversal

references/secret-patterns.md — Regex patterns, entropy-based detection, and CI/CD secret risks

Search patterns: API key, token, private key, connection string, entropy, .env, GitHub Actions, Docker, Terraform

references/language-patterns.md — Framework-specific vulnerability patterns for JavaScript, Python, Java, PHP, Go, Ruby, and Rust

Search patterns: Express, React, Next.js, Django, Flask, FastAPI, Spring Boot, PHP, Go, Rails, Rust

references/vulnerable-packages.md — Curated CVE watchlist for npm, pip, Maven, Rubygems, Cargo, and Go modules

Search patterns: lodash, axios, jsonwebtoken, Pillow, log4j, nokogiri, CVE

references/report-format.md — Structured output template for security reports with finding cards, dependency audit, secrets scan, and patch proposal formatting

Search patterns: report, format, template, finding, patch, summary, confidence