lz-advisor.security-review

The lz-advisor:security-reviewer agent is backed by a stronger model (Opus) with OWASP Top 10 expertise and threat modeling methodology. Invoke it via the Agent tool at the strategic moment described below. For guidance on timing and context packaging, see:

@${CLAUDE_PLUGIN_ROOT}/references/advisor-timing.md

@${CLAUDE_PLUGIN_ROOT}/references/context-packaging.md

This skill follows a three-phase workflow: scan, consult, then output.

## Phase 1: Scan

Determine the review scope from the user's request:

• If the user specified files or directories, read those
• If the user asked to review "recent changes" or "my changes", use git diff or git log to identify changed files, then read them
• If the user's request is in conversation context (for example, they just finished coding), review the files they were working on

Read any CLAUDE.md files in the reviewed directories -- project guidelines inform what counts as a security concern and may include security-specific constraints.

Scan the code with a security-specific lens. Focus on:

• Input handling: Where does external input enter the code? How is it validated, sanitized, escaped?
• Authentication and authorization: Are access controls present and correctly applied? Are there paths that bypass auth checks?
• Data exposure: Is sensitive data logged, leaked in error messages, or stored insecurely?
• Attack surfaces: What endpoints, interfaces, or entry points could an attacker target?
• Cryptographic usage: Are algorithms, key sizes, and modes appropriate? Are secrets hardcoded?
• Dependency risks: Are there known-vulnerable dependencies or unsafe deserialization?

Skip (do not flag):

• Code quality issues that have no security implication (style, readability, dead code)
• Theoretical vulnerabilities in code paths that are never exposed to external input
• Issues a SAST tool would flag without context (pure pattern matching)

Curate the top 3-5 highest-severity security findings with file:line references and relevant code context. For each finding, include an initial severity assessment (Critical / High / Medium).

Do not consult the security-reviewer agent during scanning. Scanning is preparation.

## Phase 2: Consult the Security Reviewer

Package the scan results and invoke the lz-advisor:security-reviewer agent via the Agent tool. Package the consultation prompt per the Verification template in @${CLAUDE_PLUGIN_ROOT}/references/context-packaging.md. This is a security-review consultation; the Threat Model Context block (assets the code protects, who might attack it, blast radius) is REQUIRED, not optional. The executor's 3-5 curated security findings become the Findings section of the template (with OWASP category tags).

One security-reviewer consultation per review invocation. The security-reviewer starts with fresh context and cannot see the conversation -- all relevant context goes in the prompt.

## Phase 3: Structure Output

Present findings to the user as console output.

Start with a summary header:

## Security Review Summary

Reviewed: [scope description -- files, directories, or change range]
Findings: [N] Critical, [N] High, [N] Medium

Then group findings by severity (Critical / High / Medium):

For each finding:

• Finding title with file:line reference and OWASP category tag (for example, [A03 Injection])
• Description with the security reviewer's threat analysis woven in seamlessly (no attribution, no separate "Threat Analysis" section)
• Attack vector and exploitability context (from the reviewer's analysis)
• Concrete remediation suggestion (specific fix, not generic advice like "validate input")

Include only findings the security reviewer validated. Drop findings the reviewer rejected.

Do not include:

• A strengths or positive observations section
• A "Recommended Action" or next-steps section
• Opus attribution tags or a separate reviewer analysis section

If the reviewer identified attack chains, present them as a connected narrative across related findings -- for example, note how an input validation gap in one finding enables escalation through a privilege check bypass in another.

Present the security review findings to the user. If no security issues were found during scanning, report that no vulnerabilities were identified in the reviewed scope and note the security aspects that were examined.