Skill

security-review

Security review methodology. STRIDE threat modeling, OWASP Top 10 vulnerability checks, auth/validation/secrets handling review, and mitigation recommendations.

Install

npx claudepluginhub codyswanngt/lisa --plugin lisa

Tool Access

This skill uses the workspace's default tool permissions.

Preview

Identify vulnerabilities, evaluate threats, and recommend mitigations for code changes.

SKILL.md

Similar Skills

cache-components

Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.

cache-components

139.2k

mcp-builder

9 files

Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).

anthropics-skills-13

124.2k

canvas-design

20 files

Generates original PNG/PDF visual art via design philosophy manifestos for posters, graphics, and static designs on user request.

anthropics-skills-13

124.2k

Stats

Parent Repo Stars1

Parent Repo Forks2

Last CommitMar 25, 2026

Actions

View Source View Plugin View on GitHub View README

Security Review

Identify vulnerabilities, evaluate threats, and recommend mitigations for code changes.

Analysis Process

Read affected files -- understand current security posture of the code being changed

STRIDE analysis -- evaluate Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege risks

Check input validation -- are user inputs sanitized at system boundaries?

Check secrets handling -- are credentials, tokens, or API keys exposed in code, logs, or error messages?

Check auth/authz -- are access controls properly enforced for new endpoints or features?

Review dependencies -- do new dependencies introduce known vulnerabilities?

Output Format

Structure findings as:

## Security Analysis ### Threat Model (STRIDE) | Threat | Applies? | Description | Mitigation | |--------|----------|-------------|------------| | Spoofing | Yes/No | ... | ... | | Tampering | Yes/No | ... | ... | | Repudiation | Yes/No | ... | ... | | Info Disclosure | Yes/No | ... | ... | | Denial of Service | Yes/No | ... | ... | | Elevation of Privilege | Yes/No | ... | ... | ### Security Checklist - [ ] Input validation at system boundaries - [ ] No secrets in code or logs - [ ] Auth/authz enforced on new endpoints - [ ] No SQL/NoSQL injection vectors - [ ] No XSS vectors in user-facing output - [ ] Dependencies free of known CVEs ### Vulnerabilities Found - [vulnerability] -- where in the code, how to prevent ### Recommendations - [recommendation] -- priority (critical/warning/suggestion)

Rules

Focus on the specific changes proposed, not a full security audit of the entire codebase

Flag only real risks -- do not invent hypothetical threats for internal tooling with no user input

Prioritize OWASP Top 10 vulnerabilities

If the changes are purely internal (config, refactoring, docs), report "No security concerns" and explain why

Always check .gitleaksignore patterns to understand what secrets scanning is already in place

Security Review

Identify vulnerabilities, evaluate threats, and recommend mitigations for code changes.

Analysis Process

Read affected files -- understand current security posture of the code being changed
STRIDE analysis -- evaluate Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege risks
Check input validation -- are user inputs sanitized at system boundaries?
Check secrets handling -- are credentials, tokens, or API keys exposed in code, logs, or error messages?
Check auth/authz -- are access controls properly enforced for new endpoints or features?
Review dependencies -- do new dependencies introduce known vulnerabilities?

Output Format

Structure findings as:

## Security Analysis

### Threat Model (STRIDE)
| Threat | Applies? | Description | Mitigation |
|--------|----------|-------------|------------|
| Spoofing | Yes/No | ... | ... |
| Tampering | Yes/No | ... | ... |
| Repudiation | Yes/No | ... | ... |
| Info Disclosure | Yes/No | ... | ... |
| Denial of Service | Yes/No | ... | ... |
| Elevation of Privilege | Yes/No | ... | ... |

### Security Checklist
- [ ] Input validation at system boundaries
- [ ] No secrets in code or logs
- [ ] Auth/authz enforced on new endpoints
- [ ] No SQL/NoSQL injection vectors
- [ ] No XSS vectors in user-facing output
- [ ] Dependencies free of known CVEs

### Vulnerabilities Found
- [vulnerability] -- where in the code, how to prevent

### Recommendations
- [recommendation] -- priority (critical/warning/suggestion)

Rules

Focus on the specific changes proposed, not a full security audit of the entire codebase
Flag only real risks -- do not invent hypothetical threats for internal tooling with no user input
Prioritize OWASP Top 10 vulnerabilities
If the changes are purely internal (config, refactoring, docs), report "No security concerns" and explain why
Always check .gitleaksignore patterns to understand what secrets scanning is already in place