| name | lisa-security-review |
| description | Security review methodology. STRIDE threat modeling, OWASP Top 10 vulnerability checks, auth/validation/secrets handling review, and mitigation recommendations. |
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
