security-review（安全审查）

Security Review

Overview

Systematically review code for security vulnerabilities, apply secure coding patterns, and ensure applications follow defense-in-depth principles. This skill covers the OWASP Top 10, authentication pattern selection, input validation, secrets management, dependency auditing, security headers, and threat modeling.

Announce at start: "I'm using the security-review skill to assess security posture."

Phase 1: Scope and Threat Assessment

Goal: Identify the attack surface and prioritize review areas.

Actions

1. Identify all user-facing endpoints and input surfaces
2. Map authentication and authorization boundaries
3. List external dependencies and their trust levels
4. Identify sensitive data flows (PII, credentials, payment)
5. Determine compliance requirements (SOC 2, GDPR, HIPAA)

STOP — Do NOT proceed to Phase 2 until:

• Attack surface is mapped
• Sensitive data flows are identified
• Compliance requirements are known

Phase 2: OWASP Top 10 Audit

Goal: Systematically check against each OWASP category.

OWASP Top 10 Checklist (2021)

STOP — Do NOT proceed to Phase 3 until:

• All 10 categories are checked
• Findings are documented with severity

Phase 3: Deep Review by Category

Goal: Apply detailed security patterns to identified issues.

Auth Pattern Selection Table

JWT Security Checklist

Input Validation Patterns

Allow-List Validation (always prefer over block-list):

# Good: allow-list
ALLOWED_SORT_FIELDS = {'name', 'created_at', 'price'}
if sort_field not in ALLOWED_SORT_FIELDS:
    raise ValidationError("Invalid sort field")

# Bad: block-list (always incomplete)
BLOCKED_CHARS = ['<', '>', '"']

Parameterized Queries (never concatenate user input):

# Good: parameterized
cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))

# Bad: SQL injection vulnerability
cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")

File Upload Validation

• Validate MIME type server-side (not just extension)
• Enforce file size limits
• Generate random filenames (never use user-supplied names)
• Store uploads outside the web root
• Scan for malware if accepting from untrusted users

STOP — Do NOT proceed to Phase 4 until:

• All identified issues have remediation recommendations
• Auth patterns are correctly applied
• Input validation is comprehensive

Phase 4: Infrastructure and Dependency Hardening

Goal: Secure the deployment environment and supply chain.

Secrets Management Rules

Secrets Never List

• Never hard-code secrets in source code
• Never commit .env files to git
• Never log secrets (even at debug level)
• Never pass secrets as command-line arguments
• Never use the same secrets across environments

Dependency Auditing Commands

# Node.js
npm audit
npx socket-security audit

# Python
pip-audit
safety check

# Go
govulncheck ./...

# Rust
cargo audit

Security Headers

CORS Rules

• Never use Access-Control-Allow-Origin: * with credentials
• Allowlist specific origins
• Restrict allowed methods and headers to what is needed

Phase 5: Threat Modeling (STRIDE)

Goal: For new features or significant changes, walk through each threat category.

For each identified threat:

1. Document the threat and attack vector
2. Assess likelihood and impact
3. Define mitigations
4. Verify mitigations are implemented and tested

Decision Table: Security Review Depth

Anti-Patterns / Common Mistakes

Secrets Rotation Schedule

Subagent Dispatch Opportunities

Follow the dispatching-parallel-agents skill protocol when dispatching.

Integration Points

Skill Type

FLEXIBLE — Adapt the depth of review to the change type using the decision table. The OWASP checklist and STRIDE analysis are strongly recommended for any auth or input-handling changes. Secrets management rules are non-negotiable.