9thlevelsoftware/legion/security-review

Security Review

Structured security review skill for Legion. Provides OWASP Top 10 checklist evaluation and STRIDE threat modeling for code and architecture review. Activates automatically when security-sensitive files are modified, or explicitly via the --security / --just-security intent flag.

Agent: engineering-security-engineer

Section 1: Activation

This skill activates when ANY of these conditions are met. All filename globs reference the canonical registry in .planning/config/intent-teams.yaml under teams.security.file_patterns[] — do not inline divergent lists in consumers.

Explicit Activation

• --security or --just-security intent flag on /legion:review
• /legion:plan --auto includes security scan (and --skip-security is NOT set)

Automatic Activation — file-pattern globs

Authoritative glob list: .planning/config/intent-teams.yaml → teams.security.file_patterns[]. Canonical set (mirror; edit the YAML first when adding):

• **/*auth*, **/*login*, **/*session*, **/*token*, **/*jwt*
• **/*password*, **/*credential*, **/*secret*, **/*encrypt*, **/*crypto*
• **/*permission*, **/*rbac*, **/*acl*, **/*role*
• **/*middleware*, **/*guard*, **/*policy*

Word-boundary rule: a file qualifies only if the glob matches the filename AND the matched token is separated by [._/\-] from alphabetic characters on both sides (so authorized_users_export.md → matches auth token; token_generator_template.md → matches token token). If your runtime's glob engine cannot enforce word boundaries, fall back to substring match but flag the finding as confidence: medium rather than high.

Restricted to source-file extensions: .py, .js, .jsx, .ts, .tsx, .rb, .go, .rs, .java, .cs, .php, .swift, .kt, .scala, .cpp, .c, .h.

Configuration files qualify ONLY when the extension is .env, .env.*, .yaml, .yml, .toml, .ini, or .json AND the file content matches the secret-token grep in Section 6.1.

Automatic Activation — authentication-decorator detection

Activate when a diff-modified file contains any of these authentication decorators/middleware markers. This list is enumerated — no generic "authentication decorators" prose trigger:

Codebase-Aware Activation

• When .planning/CODEBASE.md exists and its Risk Areas section identifies security-critical files
• When the phase type is api or security in CONTEXT.md frontmatter

Secret-token grep catalog (used by configuration-file activation)

See Section 6.1 for the authoritative grep patterns used to decide whether a configuration file with a generic extension qualifies as security-sensitive. Non-matching configs MUST NOT trigger activation by filename alone.

When NOT to activate

• Non-code phases (documentation, design, marketing)
• Phases that only modify test files or configuration comments
• When --skip-security is explicitly set

Section 2: OWASP Top 10 Checklist

Structured pass/fail evaluation for each OWASP category. The engineering-security-engineer agent evaluates each category against the code under review.

2.1: Checklist

2.2: Evaluation Process

For each OWASP category:
 
Step 1: Determine applicability
  - Is this category relevant to the files under review?
  - If not applicable (e.g., no XML parsing → XXE is N/A): mark PASS with note "N/A"
 
Step 2: Check each item
  - For each check item in the category:
    - Search the codebase for relevant patterns
    - Evaluate against the check criteria
    - Mark as PASS, FAIL, or WARN (partial compliance)
 
Step 3: Produce category verdict
  - All items PASS → Category: PASS
  - Any item FAIL with CRITICAL severity → Category: FAIL (blocker)
  - Any item FAIL with HIGH severity → Category: FAIL (must fix before ship)
  - Any item WARN → Category: WARN (recommend fixing)
 
Step 4: Record findings
  - For each FAIL or WARN: produce a structured finding (Section 8)

Section 3: STRIDE Threat Model

Apply STRIDE threat categories to each system boundary identified in the code under review.

3.1: Threat Categories

3.2: Threat Modeling Process

For each system boundary (API endpoint, data store, external integration):
 
Step 1: Identify the boundary
  - What enters and exits this boundary?
  - Who/what are the actors?
  - What data flows through?
 
Step 2: Apply STRIDE
  - For each of the 6 threat categories:
    - Is this threat applicable to this boundary?
    - What specific attack vectors exist?
    - What mitigations are in place?
    - Are mitigations sufficient?
 
Step 3: Produce threat table
  | Boundary | Threat | Category | Attack Vector | Mitigation | Status |
  |----------|--------|----------|---------------|------------|--------|
  | /api/auth/login | Brute force | DoS | Repeated login attempts | Rate limiting at 5/min | MITIGATED |
  | /api/auth/login | Credential stuffing | Spoofing | Leaked credentials | MFA + breach detection | PARTIAL |
 
Step 4: Flag gaps
  - MITIGATED: threat has adequate countermeasure
  - PARTIAL: countermeasure exists but incomplete
  - UNMITIGATED: no countermeasure — produce finding

Section 4: Attack Surface Mapping

Read from .planning/CODEBASE.md (if exists) to identify security-relevant surfaces.

4.1: Surface Categories

4.2: Mapping Process

Step 1: Read codebase context
  - If .planning/CODEBASE.md exists: extract Risk Areas, Detected Stack, Conventions
  - If not: scan project files for security-relevant patterns
 
Step 2: Enumerate surfaces
  - List all API endpoints (from route files, controller files)
  - Identify authentication entry points
  - Find data storage access patterns (database queries, file I/O)
  - Map external integrations (HTTP clients, webhook handlers)
 
Step 3: Classify risk
  - For each surface: assign risk level from the table above
  - CRITICAL surfaces get full OWASP + STRIDE treatment
  - HIGH surfaces get OWASP checklist
  - MEDIUM surfaces get targeted checks based on surface type
 
Step 4: Produce attack surface map
  Structured output showing all identified surfaces with risk levels

Section 5: Dependency Vulnerability Scan