Security Engineering

Threat-aware code review. Vulnerability detection. Risk-ranked remediation.

<when_to_use>

• Security audits and code reviews
• Authentication/authorization review
• Input validation and sanitization checks
• Cryptographic implementation review
• Dependency and supply chain security
• Threat modeling for new features

NOT for: performance optimization, general code review, feature implementation

</when_to_use>

Load the maintain-tasks skill for stage tracking. Each stage feeds the next.

Critical findings: add urgent remediation task immediately.

<severity_levels>

CVSS-aligned severity for findings:

Format: “Critical RCE via unsanitized shell command”

</severity_levels>

<threat_modeling>

STRIDE Framework

Systematic threat identification by category:

Attack Trees

Map paths from attacker goal to entry points:

Goal: Steal credentials
- Attack login
  - SQLi in username
  - Brute force (no rate limit)
  - Session fixation
- Intercept traffic
  - HTTPS downgrade
  - MITM
- Exploit reset
  - Predictable token
  - No expiry

For each branch assess: feasibility, impact, detection, current defenses.

Trust Boundaries

Identify where data crosses trust levels:

• Browser to server
• Server to database
• Service to third-party API
• Internal service to service

Every boundary needs validation.

</threat_modeling>

<attack_surface>

Entry Points

External:

• HTTP/API endpoints (REST, GraphQL, gRPC)
• WebSocket connections
• File uploads
• OAuth/SAML flows
• Webhooks

Data Inputs:

• User data (forms, query params, headers)
• File content (type, size, payload)
• API payloads (JSON, XML)
• Database queries

Auth Boundaries:

• Public (no auth)
• Authenticated
• Admin/privileged
• Service-to-service

Prioritize Review

1. Unauthenticated external inputs
2. Privileged operations
3. Data persistence layers
4. Third-party integrations

For each entry point document:

• Auth required? (none/user/admin)
• Input validated? (none/basic/strict)
• Rate limited?
• Logged?
• Encrypted?

</attack_surface>

<vulnerability_patterns>

Quick Reference

Critical Checks

Authentication:

• Passwords: bcrypt/argon2, cost 12+
• Sessions: crypto.randomBytes(32), httpOnly, secure, sameSite
• JWT: verify signature, specify algorithm, short expiry
• Reset: random token, 1hr expiry, hash stored token

Authorization:

• Server-side on every request
• Verify ownership before resource access
• Explicit allowlist for mass assignment
• No role elevation from client input

Input Validation:

• Type, length, format on all inputs
• Parameterized queries (never concat)
• Escape/sanitize HTML output
• Validate file uploads (type, size, content)

Cryptography:

• AES-256-GCM, SHA-256+
• Never MD5, SHA1, DES, ECB
• Secrets from env, never hardcoded
• crypto.randomBytes for all tokens

See vulnerability-patterns.md for code examples.

</vulnerability_patterns>

<owasp_top_10>

2021 OWASP Top 10 categories. Check each during vulnerability scan.

See owasp-top-10.md for detailed breakdowns with code examples.

</owasp_top_10>

Loop: Model Threats -> Map Surface -> Scan Vulnerabilities -> Assess Risk -> Plan Remediation

1. Threat Model

   • STRIDE analysis for component
   • Attack trees for critical paths
   • Identify trust boundaries
   • Document threat actors

2. Attack Surface

   • Inventory all inputs
   • Classify by auth level
   • Map data flows across boundaries
   • Prioritize high-risk entry points

3. Vulnerability Scan

   • Check each entry against OWASP Top 10
   • Review auth/authz
   • Validate input handling
   • Check crypto usage
   • Scan deps: npm audit, cargo audit

4. Risk Assessment

   • Rate severity (Critical/High/Medium/Low)
   • Consider exploitability
   • Assess impact (CIA triad)
   • Calculate risk score

5. Remediation Plan

   • Critical: immediate action
   • High: fix before release
   • Medium: schedule in sprint
   • Low: backlog or accept

Update todos as you progress. Use review-checklist.md for verification.

Finding Format

## {SEVERITY} {VULN_NAME}

**Category**: {OWASP} | **CWE**: {ID} | **File**: {PATH}:{LINES}

### Issue
{CLEAR_EXPLANATION}

### Impact
{WHAT_ATTACKER_COULD_DO}

### Fix
{SPECIFIC_REMEDIATION_WITH_CODE}

Summary Format

# Security Audit: {SCOPE}

| Severity | Count |
|----------|-------|
| Critical | N |
| High | N |
| Medium | N |
| Low | N |

## Key Findings
1. {TOP_CRITICAL}
2. {SECOND}
3. {THIRD}

## Recommendations
- Immediate: {CRITICAL_FIXES}
- Short-term: {HIGH_MEDIUM}
- Long-term: {HARDENING}

See report-templates.md for full templates.

ALWAYS:

• Start with threat modeling before code review
• Map complete attack surface
• Check against all OWASP Top 10 categories
• Use severity indicators consistently
• Provide specific remediation with code
• Verify fixes don’t introduce new vulnerabilities
• Document security assumptions
• Update todos when transitioning stages

NEVER:

• Skip threat modeling for “simple” features
• Assume input is trustworthy
• Rely on client-side security
• Use deprecated crypto (MD5, SHA1, DES)
• Log sensitive data
• Disable security checks “temporarily”
• Mark complete without remediation plan

Deep dives:

• vulnerability-patterns.md – secure vs vulnerable code examples
• owasp-top-10.md – detailed OWASP categories with CWE mappings
• review-checklist.md – complete security review checklist
• report-templates.md – finding and audit report templates

Related skills:

• codebase-recon – evidence-based investigation foundation
• debugging – when security issues manifest as bugs

External:

• OWASP Top 10
• CWE Database
• OWASP Cheat Sheets