| name | security |
| description | Use when reviewing code for security vulnerabilities, before shipping to production, or when the user asks for a security audit. Runs OWASP Top 10 + STRIDE analysis with a strict false positive filter. Confidence gate at 8/10. No theoretical hand-waving.
|
| version | 1.0.0 |
Security Audit
The Scan
1. Map the attack surface
- Grep for routes, auth handlers, external integrations, file uploads, admin endpoints
- List all entry points (API routes, webhooks, scheduled jobs, CLI commands)
2. OWASP Top 10 pass
For each entry point, check:
| Category | Look for |
|---|
| A01 Broken Access Control | Missing auth checks, direct object references, path traversal |
| A02 Crypto Failures | Weak algorithms, hardcoded secrets, plaintext storage |
| A03 Injection | SQL, command, template, LLM prompt injection |
| A04 Insecure Design | Business logic flaws, missing rate limits |
| A05 Misconfiguration | Debug mode, default creds, overly permissive CORS |
| A06 Vulnerable Components | Outdated deps with known CVEs |
| A07 Auth Failures | Weak passwords, missing MFA, session fixation |
| A08 Integrity Failures | Unsigned updates, untrusted CI/CD inputs |
| A09 Logging Gaps | Missing audit trail, logging sensitive data |
| A10 SSRF | User-controlled URLs fetched server-side |
3. STRIDE per component
For each significant component: can an attacker achieve Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, or Elevation of Privilege?
4. Data classification
Tag all stored/transmitted data as:
- RESTRICTED - credentials, PII, financial data
- CONFIDENTIAL - internal business logic, configs
- INTERNAL - non-sensitive but not public
- PUBLIC - safe to expose
The Filter (the actually valuable part)
Hard exclusions, don't report these:
- DoS via resource exhaustion (unless trivially exploitable)
- Test-only code vulnerabilities
- Memory safety in memory-safe languages
- Log spoofing / log injection
- Missing CSP headers (unless XSS is also present)
- Theoretical timing attacks without proof
- Missing X-Frame-Options when CSP frame-ancestors is set
- Self-XSS (requires attacker to control own browser)
- Open redirects without auth token leakage
- Missing rate limiting on non-auth endpoints
- Verbose error messages in development mode
- Cookie without Secure flag on localhost
- Missing HSTS on internal-only services
- Theoretical ReDoS without proof of exploitable input
- Information disclosure via stack traces in dev mode
Precedents, assume these are fine unless proven otherwise:
- UUIDs are unguessable
- Environment variables are trusted
- Client-side JS doesn't need server-side auth
- ORM-generated queries are injection-safe
- Framework CSRF protection works when enabled
- HTTPS is enforced at infra level
- Container isolation is effective
- Cloud IAM roles are correctly scoped
Rules
- Confidence gate: 8/10 minimum. If you're not at least 80% sure it's real, don't report it.
- Every finding needs an exploit scenario. Step-by-step: what does the attacker do, what do they get? No hand-waving.
