Lisa Security Review

Security Review

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

Analysis Process

1. Read affected files -- understand current security posture of the code being changed
2. STRIDE analysis -- evaluate Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege risks
3. Check input validation -- are user inputs sanitized at system boundaries?
4. Check secrets handling -- are credentials, tokens, or API keys exposed in code, logs, or error messages?
5. Check auth/authz -- are access controls properly enforced for new endpoints or features?
6. 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