dededecline/claude/skills/security-review

Security Review

Comprehensive security-focused code review methodology for identifying high-confidence vulnerabilities in code changes. Implements multi-phase analysis with rigorous false positive filtering.

Step 1: Gather Context

Before beginning analysis, collect the following information:

Git State

Run these commands to understand the scope of changes:

# Current status
git status

# Files modified on this branch vs origin
git diff --name-only origin/HEAD...

# Commit history for this branch
git log --no-decorate origin/HEAD...

# Full diff content (the primary input for review)
git diff --merge-base origin/HEAD

If the branch has no remote tracking or origin/HEAD is not set, adapt accordingly (e.g., diff against main or master).

Repository Exploration

Use file search and reading 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 security model and threat model

Step 2: Security Analysis

Objective

Perform a security-focused code review to identify HIGH-CONFIDENCE security vulnerabilities that could have real exploitation potential. This is not a general code review -- focus ONLY on security implications newly added by the changes under review. Do not comment on existing security concerns.

Critical Instructions

1. MINIMIZE FALSE POSITIVES: Only flag issues where you are >80% confident of actual exploitability
2. AVOID NOISE: Skip theoretical issues, style concerns, or low-impact findings
3. FOCUS ON IMPACT: Prioritize vulnerabilities that could lead to unauthorized access, data breaches, or system compromise
4. EXCLUSIONS: Do NOT report the following issue types:
   • Denial of Service (DOS) vulnerabilities, even if they allow service disruption
   • Secrets or sensitive data stored on disk (these are handled by other processes)
   • Rate limiting or resource exhaustion issues

Security Categories to Examine

Input Validation Vulnerabilities:

• SQL injection via unsanitized user input
• Command injection in system calls or subprocesses
• XXE injection in XML parsing
• Template injection in templating engines
• NoSQL injection in database queries
• Path traversal in file operations

Authentication & Authorization Issues:

• Authentication bypass logic
• Privilege escalation paths
• Session management flaws
• JWT token vulnerabilities
• Authorization logic bypasses

Crypto & Secrets Management:

• Hardcoded API keys, passwords, or tokens
• Weak cryptographic algorithms or implementations
• Improper key storage or management
• Cryptographic randomness issues
• Certificate validation bypasses

Injection & Code Execution:

• Remote code execution via deserialization
• Pickle injection in Python
• YAML deserialization vulnerabilities
• Eval injection in dynamic code execution
• XSS vulnerabilities in web applications (reflected, stored, DOM-based)

Data Exposure:

• Sensitive data logging or storage
• PII handling violations
• API endpoint data leakage
• Debug information exposure

Additional Notes

• Even if something is only exploitable from the local network, it can still be a HIGH severity issue

Step 3: Analysis Methodology

Phase 1 - Repository Context Research

Use file search and reading 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 security model and threat model

Phase 2 - Comparative Analysis

• Compare new code changes 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 being crossed unsafely
• Identify injection points and unsafe deserialization

Step 4: Multi-Step Execution

Execute the analysis in 3 discrete steps:

1. Sub-task: Vulnerability Identification - Use repository exploration tools to understand the codebase context, then analyze the changes for security implications. Apply all security categories, methodology phases, and severity/confidence guidelines described in this skill.

2. Sub-tasks: False Positive Filtering (parallel) - For each vulnerability identified in step 1, create a separate sub-task to evaluate it against the false positive filtering rules below. Launch these sub-tasks in parallel.

3. Confidence Threshold - Filter out any vulnerabilities where the false-positive filtering sub-task reported a confidence score less than 8.

Output Format

Output findings in markdown. Each finding must contain the file, line number, severity, category (e.g., sql_injection or xss), description, exploit scenario, and fix recommendation.

Example:

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

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

Severity Guidelines

• HIGH: Directly exploitable vulnerabilities leading to RCE, data breach, or authentication bypass
• MEDIUM: Vulnerabilities requiring specific conditions but with significant impact
• LOW: Defense-in-depth issues or lower-impact vulnerabilities

Confidence Scoring

• 0.9-1.0: Certain exploit path identified, tested if possible
• 0.8-0.9: Clear vulnerability pattern with known exploitation methods
• 0.7-0.8: Suspicious pattern requiring specific conditions to exploit
• Below 0.7: Do not report (too speculative)

Final Reminder

Focus on HIGH and MEDIUM findings only. 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.

False Positive Filtering Rules

These rules are applied during step 2 (per-finding sub-tasks). Do not use bash to reproduce vulnerabilities -- read the code to determine if it is a real vulnerability. Do not write to any files.

Hard Exclusions

Automatically exclude findings matching these patterns:

1. Denial of Service (DOS) vulnerabilities or resource exhaustion attacks
2. Secrets or credentials stored on disk if they are otherwise secured
3. Rate limiting concerns or service overload scenarios
4. Memory consumption 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 they are clearly triggerable via untrusted input
7. A lack of hardening measures -- code is not expected to implement all security best practices; only flag concrete vulnerabilities
8. Race conditions or timing attacks that are theoretical rather than practical issues -- only report a race condition if it is concretely problematic
9. Vulnerabilities related to outdated third-party libraries -- these are managed separately and should not be reported here
10. Memory safety issues such as buffer overflows or use-after-free vulnerabilities are impossible in Rust -- do not report memory safety issues in Rust or any other memory-safe language
11. Files that are only unit tests or only used as part of running tests
12. Log spoofing concerns -- outputting unsanitized user input to logs is not a vulnerability
13. SSRF vulnerabilities that only control the path -- SSRF is only a concern if it can control the host or protocol
14. Including user-controlled content in AI system prompts is not a vulnerability
15. Regex injection -- injecting untrusted content into a regex is not a vulnerability
16. Regex DOS concerns
17. Insecure documentation -- do not report any findings in documentation files such as markdown files
18. A lack of audit logs is not a vulnerability

Precedents

1. Logging high-value secrets in plaintext is a vulnerability. Logging URLs is assumed to be safe.
2. UUIDs can be assumed to be unguessable and do not need to be validated.
3. Environment variables and CLI flags are trusted values. Attackers are generally not able to modify them in a secure environment. Any attack that relies on controlling an environment variable is invalid.
4. Resource management issues such as memory or file descriptor leaks are not valid.
5. Subtle or low-impact web vulnerabilities such as tabnabbing, XS-Leaks, prototype pollution, and open redirects should not be reported unless they are extremely high confidence.
6. React and Angular are generally secure against XSS. These frameworks do not need to sanitize or escape user input unless using unsafe innerHTML methods (e.g., React's dangerouslySetInnerHTML or Angular's bypassSecurityTrustHtml). Do not report XSS vulnerabilities in React or Angular components or TSX files unless they use such unsafe methods.
7. Most vulnerabilities in GitHub Action workflows are not exploitable in practice. Before validating a GitHub Action workflow vulnerability, ensure it is concrete and has a very specific attack path.
8. A lack of permission checking or authentication in client-side JS/TS code is not a vulnerability. Client-side code is not trusted and does not need to implement these checks; they are handled on the server-side. The same applies to all flows that send untrusted data to the backend -- the backend is responsible for validating and sanitizing all inputs.
9. Only include MEDIUM findings if they are obvious and concrete issues.
10. Most vulnerabilities in IPython notebooks (*.ipynb files) are not exploitable in practice. Before validating a notebook vulnerability, ensure it is concrete and has a very specific attack path where untrusted input can trigger the vulnerability.
11. Logging non-PII data is not a vulnerability even if the data may be sensitive. Only report logging vulnerabilities if they expose sensitive information such as secrets, passwords, or personally identifiable information (PII).
12. Command injection vulnerabilities in shell scripts are generally not exploitable in practice since shell scripts generally do not run with untrusted user input. Only report command injection vulnerabilities in shell scripts if they are concrete and have a very specific attack path for untrusted input.

Signal Quality Criteria

For remaining findings, assess:

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

For each finding, assign a confidence score from 1-10:

• 1-3: Low confidence, likely false positive or noise
• 4-6: Medium confidence, needs investigation
• 7-10: High confidence, likely true vulnerability

Final Output

The final reply must contain only the markdown report with findings that passed all filtering (confidence >= 8). If no vulnerabilities meet the threshold, state that the review found no high-confidence security issues.