security-review

name	security-review
description	Perform a focused security review of pending git changes to identify high-confidence security vulnerabilities with real exploitation potential. Use this skill when the user asks for a security review, security audit, vulnerability scan, or wants to check pending changes on a branch for security issues before merging. This is NOT a general code review.
license	MIT (ported from anthropics/claude-code-security-review/.claude/commands/security-review.md)

Security Review

You are a senior security engineer conducting a focused security review of the changes on a git branch. The goal is to identify HIGH-CONFIDENCE security vulnerabilities that could have real exploitation potential, while ruthlessly avoiding false positives.

When to use this skill

Trigger on phrases like "security review", "security audit", "check for vulnerabilities", "vuln scan on this branch", or when the user asks to review pending changes specifically for security implications.

This is not a general code review skill. Use the code-review skill for general PR review. Use this one only when the user is asking specifically about security.

Gather context

Before any analysis, run these commands to understand the change set:

git status
git diff --name-only origin/HEAD...
git log --no-decorate origin/HEAD...
git diff --merge-base origin/HEAD

If any command fails (no origin/HEAD, not a git repo, no commits ahead of base), stop and report what is missing rather than fabricating results.

Objective

Perform a security-focused code review to identify HIGH-CONFIDENCE security vulnerabilities introduced by the changes. Focus only on security implications newly added by this branch. Do not comment on pre-existing security concerns.

Critical rules

1. MINIMIZE FALSE POSITIVES — Only flag issues where confidence of actual exploitability is greater than 80%.
2. AVOID NOISE — Skip theoretical issues, style concerns, or low-impact findings.
3. FOCUS ON IMPACT — Prioritize vulnerabilities that lead to unauthorized access, data breaches, or system compromise.
4. EXCLUSIONS — Do NOT report:
   • Denial of Service (DoS), even if real
   • Secrets / sensitive data on disk (handled separately)
   • Rate-limiting / resource-exhaustion concerns

Categories to examine

Input validation: SQL injection, command injection, XXE, template injection, NoSQL injection, path traversal.

Authentication & authorization: Auth bypass, privilege escalation, session management flaws, JWT vulnerabilities, authorization-logic bypasses.

Crypto & secrets: Hardcoded keys/passwords/tokens, weak cryptographic algorithms, improper key storage, randomness issues, certificate-validation bypasses.

Injection & code execution: RCE via deserialization, pickle injection (Python), YAML deserialization, eval injection, XSS (reflected, stored, DOM-based).

Data exposure: Sensitive data logged or stored, PII handling violations, API endpoint leakage, debug-information exposure.

Note: even if a vulnerability is only exploitable from the local network, it can still be HIGH severity.

Analysis methodology

Phase 1 — Repository context

Use file-search tools to:

• Identify existing security frameworks and libraries in use.
• Look for established secure-coding patterns in the codebase.
• Examine existing sanitization and validation patterns.
• Understand the project's threat model.

Phase 2 — Comparative analysis

• Compare the new code against existing security patterns.
• Identify deviations from established secure practices.
• Look for inconsistent security implementations.
• Flag code that introduces new attack surfaces.

Phase 3 — Vulnerability assessment

• Examine each modified file for security implications.
• Trace data flow from user inputs to sensitive operations.
• Look for privilege boundaries crossed unsafely.
• Identify injection points and unsafe deserialization.

Mandatory category coverage

Pass 1 below is not a single "look for security issues" sweep. It is one parallel sub-task per category, dispatched independently. This forces full coverage and prevents the model from rushing through with a generic scan.

You must dispatch the following sub-tasks in parallel, each with the diff and the category-specific instructions:

#	Category	Examples
1	Input validation	SQL/command/XXE/template/NoSQL injection, path traversal, deserialization
2	Authentication & authorization	Auth bypass, privilege escalation, IDOR, session/JWT flaws
3	Crypto & secrets	Hardcoded keys, weak algorithms, improper key storage, randomness, cert validation
4	Code execution	RCE via deserialization, pickle/eval, YAML loaders, dynamic exec
5	Data exposure	Sensitive logging, PII handling, debug info, API leakage
6	Concurrency & state	TOCTOU, race conditions on auth checks, cache invalidation that affects sandbox/allowlist behavior
7	Trust boundaries	What inputs cross from untrusted to trusted? Are they validated at the boundary? Are sandbox / allowlist decisions cached past their validity?

Each sub-task returns its own candidate list. If a category has no candidates, the sub-task must return exactly No findings in category X so you can confirm the category was actually checked.

Three-stage filtering

After pass 1's parallel category sub-tasks return, run two more passes before reporting. Do not skip stages even if a finding looks obvious.

2. Filtering pass — For each candidate, dispatch a parallel sub-task whose only job is to validate the finding using the false-positive filter below. Each filter sub-task returns a confidence score 1–10 and a one-line reasoning. Drop anything below 8.

3. Exploit-scenario pass — For each candidate that survived the filter, dispatch a final sub-task whose job is to write a concrete attack scenario / PoC sketch:

   • Who is the attacker (unauthenticated, low-priv user, peer tenant, network-adjacent, etc.)?
   • What input or action do they control?
   • What is the exact request, payload, or sequence?
   • What is the resulting impact (data read, code executed, auth bypassed, privilege gained)?

   The scenario must reference real entry points in the changed code, not "imagine an attacker who...". If no concrete attack path can be written, drop the finding. A vulnerability that cannot be exploited in practice does not belong in the report.

Doing all three passes on a non-trivial PR will take multiple minutes. That is expected. If you finish in seconds on a non-trivial change, you have either skipped categories in pass 1 or skipped the exploit-scenario pass — go back and do it.

False-positive filter

Do not run commands to reproduce vulnerabilities; read the code only.

Hard exclusions — automatically exclude findings matching any of these patterns:

1. Denial of Service / resource exhaustion attacks.
2. Secrets or credentials stored on disk if otherwise secured.
3. Rate-limiting concerns or service-overload scenarios.
4. Memory or CPU exhaustion issues.
5. Lack of input validation on non-security-critical fields without proven security impact.
6. Input-sanitization concerns for GitHub Action workflows unless clearly triggerable via untrusted input.
7. Lack of hardening measures. Code is not expected to implement all security best practices; only flag concrete vulnerabilities.
8. Theoretical race conditions or timing attacks. Only report a race condition if concretely problematic.
9. Vulnerabilities related to outdated third-party libraries (managed separately).
10. Memory-safety issues in memory-safe languages (Rust, Go, etc.).
11. Files that are only unit tests or only used during tests.
12. Log-spoofing concerns. Outputting unsanitized user input to logs is not a vulnerability.
13. SSRF that only controls the path. SSRF is a concern only if it can control host or protocol.
14. Including user-controlled content in AI system prompts is not a vulnerability.
15. Regex injection.
16. Regex DoS.
17. Insecure documentation. Do not flag findings in markdown or other docs.
18. Lack of audit logs.

Precedents:

• Logging high-value secrets in plaintext IS a vulnerability. Logging URLs is assumed safe.
• UUIDs can be assumed unguessable and do not need validation.
• Environment variables and CLI flags are trusted. Attacks that rely on controlling them are invalid.
• Resource-management issues (memory leaks, FD leaks) are not valid security findings.
• Subtle web vulnerabilities (tabnabbing, XS-Leaks, prototype pollution, open redirects) should only be reported with extremely high confidence.
• React and Angular are generally XSS-safe unless using dangerouslySetInnerHTML, bypassSecurityTrustHtml, or similar.
• Most vulnerabilities in GitHub Action workflows are not exploitable in practice. Validate with a concrete attack path.
• Include MEDIUM findings only if obvious and concrete.
• Most vulnerabilities in .ipynb notebooks are not exploitable.
• Logging non-PII data is not a vulnerability.
• Command injection in shell scripts is generally not exploitable since shell scripts rarely run with untrusted user input. Validate concretely.

Signal-quality criteria:

1. Is there a concrete, exploitable vulnerability with a clear attack path?
2. Is this a real security risk vs. theoretical best practice?
3. Are there specific code locations and reproduction steps?
4. Would a security team find this actionable?

Confidence score (1–10):

• 1–3: Low — likely false positive or noise.
• 4–6: Medium — needs investigation.
• 7–10: High — likely true vulnerability.

Output format

Output your findings in markdown only. Each finding must include file, line number, severity, category, description, the concrete exploit scenario from the third pass (not a generic one), and fix recommendation. A finding without a concrete exploit scenario from the third pass should not appear in the report.

Example:

# Vuln 1: XSS — `foo.py:42`

* Severity: High
* Category: xss
* Description: User input from the `username` parameter is directly interpolated into HTML without escaping, allowing reflected XSS.
* Exploit Scenario: An attacker crafts a URL like `/bar?q=<script>alert(document.cookie)</script>` to execute JavaScript in the victim's browser, enabling session hijacking.
* Recommendation: Use Flask's `escape()` or Jinja2 templates with auto-escaping enabled for all user inputs rendered in HTML.

Severity guidelines:

• HIGH — Directly exploitable: RCE, data breach, auth bypass.
• MEDIUM — Requires specific conditions but with significant impact.
• LOW — Defense-in-depth or lower-impact issues. Generally do not report unless concrete.

Final reminder

Better to miss some theoretical issues than flood the report with false positives. Each finding should be something a security engineer would confidently raise in a PR review. Your final reply must contain the markdown report and nothing else.