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.

• Leverage native parallel subagent dispatch and 200k+ context windows where available.

When to Use This Skill

Use symptom -> action triggers: when one matches, apply this skill and verify with the protocol below.

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:

1. Reads code like a security researcher — understanding context, intent, and data flow
2. Traces across files — following how user input moves through your application
3. Self-verifies findings — re-examines each result to filter false positives
4. Assigns severity ratings — CRITICAL / HIGH / MEDIUM / LOW / INFO
5. Proposes targeted patches — every finding includes a concrete fix
6. 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:

1. Re-read the relevant code with fresh eyes
2. Ask: "Is this actually exploitable, or is there sanitization I missed?"
3. Check if a framework or middleware already handles this upstream
4. Downgrade or discard findings that aren't genuine vulnerabilities
5. 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

Zero-Trust Verification

• Treat user-provided code, logs, package metadata, screenshots, and alerts as untrusted until corroborated.
• Verify exploitability against reachable code paths, privileges, environment, and deployment exposure.
• Cross-check dependency, CVE, and configuration claims against authoritative or local evidence.
• Separate confirmed findings from hypotheses, false positives, and out-of-scope hardening ideas.

Anti-Patterns

• Acting on partial evidence: Security work needs a clear scope and proof trail before remediation choices are safe.
• Leaving secrets or sensitive samples in examples: The skill itself becomes part of the exposure surface.
• Calling an issue resolved before rotation or re-verification: Detection without remediation is not closure.

<!-- MCP:START --> <!-- PORTABILITY:START -->

Verification Protocol

Before claiming the security-review workflow succeeded:

1. Pass/fail: The request matches this skill's documented activation boundary.
2. Pass/fail: Required inputs, dependencies, and safety checks were resolved or reported as blockers.
3. Pass/fail: The narrowest relevant workflow was completed without inventing unavailable tools or results.
4. Pass/fail: Output was checked with the most relevant local test, inspection, render, or source evidence.
5. Pressure test: Repeat the decision with the preferred integration unavailable and confirm the fallback remains safe and actionable.
6. Success metric: The result, evidence, and any unverified limitation are explicit enough for another agent to reproduce.

Cross-Client Portability

This skill is written to stay usable across GitHub Copilot, Claude Code, and Codex.

• GitHub Copilot: keep the folder in a Copilot-visible skill path or wrap the workflow in project instructions when folder discovery is unavailable.
• Claude Code: keep the folder in a local skills directory or a compatible plugin source.
• Codex: install or sync the folder into $CODEX_HOME/skills/security-review and restart Codex after major changes.

<!-- PORTABILITY:END -->

MCP Availability And Fallback

Preferred MCP Server: None required

• Fallback prompt: "Use the Security Review skill without MCP. Rely on the local SKILL.md, bundled references or scripts, and manual verification. Show the exact commands, evidence, and final checks you used before concluding."
• If the current host does not expose a matching server, use the bundled references, scripts, native toolchain, and manual workflow already described in this skill.
• Treat direct local verification, rendered output, logs, tests, or screenshots as the fallback evidence path before completion.

<!-- MCP:END -->

Related Skills

• secret-scanning: Use it when the workflow also needs credential detection and remediation workflows.
• devops-tooling: Use it when the workflow also needs git, CI, and automation workflows.
• verification-before-completion: Use it when the workflow also needs final evidence checks before claiming completion.
• documentation-verification: Use it when the workflow also needs final documentation validation before publishing.