Agent Skills: Differential Security Review

Differential Security Review

Review code changes as security regressions relative to a baseline. Focus on changed behavior, removed invariants, reachable attack paths, and test coverage.

Routing

• Use code-reviewer for ordinary bug-focused or quick code review.
• Use this skill when the user asks for security, audit, regression, blast radius, adversarial review, or when the diff touches auth, authorization, crypto, validation, secrets, external calls, data exposure, or value transfer.
• If the user explicitly asks for a quick summary, scale the report down and state coverage limits instead of forcing a full audit artifact.

Retrieval Rules

Read the narrowest reference needed:

| Need | Reference | |---|---| | Detailed phases 0-4 | methodology.md | | Attacker modeling and exploitability | adversarial.md | | Final report template | reporting.md | | Vulnerability pattern lookup | patterns.md | | Previous full skill text | references/full-workflow.md |

Core Principles

1. Risk-first: Spend depth on auth, crypto, value transfer, external calls, validation, secrets, and data exposure.
2. Evidence-based: Every finding needs changed code lines, concrete scenario, and security impact.
3. Differential: Look for removed checks, widened access, changed trust boundaries, and broken historical fixes.
4. Adaptive: Scale to codebase size and user intent; be explicit about coverage limits.
5. Adversarial when needed: For high-risk changes, model the attacker and exploit path.

Risk Triage

| Risk | Triggers | Depth | |---|---|---| | High | Auth, authorization, crypto, external calls, value transfer, validation removal, secrets, data exposure | Read history, callers, tests, and adversarial reference | | Medium | Business logic, persistence, state transitions, public APIs, concurrency | Read changed files and direct dependencies | | Low | Comments, tests, formatting, logging-only changes | Surface scan unless coupled to high-risk code |

Treat “refactor” as high risk until preserved invariants are proven when the touched path is security-sensitive.

Workflow

1. Establish baseline: diff range, changed files, purpose, and security-relevant surfaces.
2. Classify each changed file by risk.
3. Read high-risk changed files in full, plus direct callers, callees, config, tests, and entry points.
4. Check git history for removed security code or previous fixes:

   git log -S "pattern" --all --oneline --grep="fix\|security\|CVE"
   git blame <file>
   

5. Estimate blast radius for high-risk changes: externally reachable routes, callers, tenants/users affected, privilege boundaries crossed.
6. Check test coverage for changed invariants. Missing tests elevate uncertainty and may elevate severity.
7. For high-risk findings, create concrete attack scenarios and exploitability ratings using adversarial.md.
8. Generate a report file when the user asked for an audit/report or the review is substantial; otherwise provide concise findings in chat.

Red Flags

Stop and investigate immediately when you see:

• Removed or weakened permission checks, ownership checks, role checks, or validation.
• internal to external, private route to public route, or broader token/session acceptance.
• Algorithm/mode changes, signature verification changes, key handling changes, or disabled TLS/verification.
• External calls before state updates, missing idempotency, or value transfer without replay protection.
• High blast radius plus any high-risk trigger.

Evidence Standard

Before reporting:

• Cite file:line for the changed or directly affected code.
• Provide a concrete attacker action or failure sequence.
• Explain the security property that fails.
• Distinguish Confirmed, Likely, and Design concern.
• Drop generic findings without a reachable scenario.

Output

Order findings by severity. Use this format:

**[SEVERITY] [CONFIDENCE]** Brief description
`file:line` - Evidence from the diff and surrounding code.
Attack scenario: Concrete sequence an attacker or untrusted caller can perform.
Impact: Confidentiality, integrity, availability, privilege, funds/value, or compliance impact.
Suggested fix: Smallest safe change or invariant-restoring direction.

If generating a report file, use reporting.md and tell the user the path. If no confirmed issues are found, say what was reviewed, what validation ran or was skipped, and any coverage limits.