AI security audit

---
name: security-auditor
description: Perform a security audit covering OWASP Top 10, dependency vulnerabilities, authentication flows, and data handling. Use when reviewing code for security issues before launch, after incidents, or during regular security reviews.
allowed-tools: ["Read", "Bash", "Glob", "Grep"]
---

# /security-audit

Run a comprehensive security audit on a codebase, checking for OWASP Top 10 vulnerabilities, insecure dependencies, authentication weaknesses, and data handling issues.

## What This Command Does

1. Scans the codebase for common vulnerability patterns
2. Checks dependencies for known security advisories
3. Reviews authentication and authorization logic
4. Inspects data handling for injection, leakage, and exposure risks
5. Evaluates secrets management and configuration security
6. Produces a prioritized findings report with remediation guidance

## Usage

```
/security-audit [target-path] [--focus area] [--severity minimum-level]
```

**Examples:**
- `/security-audit src/` -- full audit of the source directory
- `/security-audit src/api/ --focus auth` -- focus on authentication logic
- `/security-audit . --severity high` -- only report high and critical findings
- `/security-audit src/services/payment.ts` -- audit a sensitive file

## Execution Steps

1. **Reconnaissance**

   Before diving into specific checks, understand the application:
   - Identify the language and framework (check `package.json`, `Cargo.toml`, `requirements.txt`, etc.)
   - Identify authentication method (JWT, sessions, OAuth, API keys)
   - Identify data stores (database, file system, external APIs)
   - Identify external integrations and API boundaries
   - Check for a `.env.example` or config schema to understand environment variables

2. **Dependency vulnerability scan**

   Run the appropriate package audit tool:

   ```bash
   # Node.js
   npm audit --json

   # Python
   pip audit

   # Rust
   cargo audit
   ```

   For each vulnerability found:
   - Record the package name, severity, and CVE identifier
   - Check if an upgrade is available
   - Assess whether the vulnerable code path is actually reachable in this project

3. **OWASP Top 10 checks**

   Systematically check for each category:

   ### A01: Broken Access Control
   - Search for authorization checks on all API endpoints/routes
   - Look for missing role/permission checks
   - Check for IDOR (Insecure Direct Object Reference): are user-owned resources accessed by ID without ownership verification?
   - Search for `admin`, `role`, `permission` patterns and verify they are enforced server-side
   - Check that sensitive endpoints require authentication

   ### A02: Cryptographic Failures
   - Search for hardcoded secrets, API keys, passwords in source code
   - Check that passwords are hashed with bcrypt, scrypt, or argon2 (not MD5, SHA1, or SHA256 alone)
   - Verify HTTPS is enforced (no HTTP URLs for sensitive operations)
   - Check for proper TLS configuration
   - Look for encryption key management (keys should not be in source code)

   ### A03: Injection
   - Search for SQL queries built with string concatenation or template literals
   - Check for parameterized queries / prepared statements
   - Look for command injection risks (user input passed to shell commands)
   - Check for XSS vectors: user input rendered without sanitization in HTML
   - Look for LDAP, XML, or NoSQL injection patterns

   ### A04: Insecure Design
   - Check rate limiting on authentication endpoints
   - Verify account lockout after failed login attempts
   - Look for missing CSRF protection on state-changing requests
   - Check for security-relevant business logic flaws

   ### A05: Security Misconfiguration
   - Check for debug mode or verbose error messages in production config
   - Verify CORS settings are restrictive (not `*` for authenticated endpoints)
   - Check for default credentials in configuration
   - Verify security headers (CSP, X-Frame-Options, X-Content-Type-Options)
   - Check that directory listing is disabled

   ### A06: Vulnerable and Outdated Components
   - Covered by the dependency scan in step 2
   - Additionally check for deprecated APIs or functions in the language/framework

   ### A07: Identification and Authentication Failures
   - Check password strength requirements
   - Verify session management (timeout, regeneration after login, secure cookie flags)
   - Check JWT implementation (algorithm specified, expiration set, secret strength)
   - Look for credential exposure in logs or error messages

   ### A08: Software and Data Integrity Failures
   - Check for integrity verification on external resources (SRI hashes on CDN scripts)
   - Verify CI/CD pipeline security (no secrets in build logs)
   - Check for deserialization of untrusted data

   ### A09: Security Logging and Monitoring Failures
   - Check that authentication events are logged (login, logout, failed attempts)
   - Verify that logs do not contain sensitive data (passwords, tokens, PII)
   - Check for error handling that silently swallows security-relevant failures

   ### A10: Server-Side Request Forgery (SSRF)
   - Search for user-controllable URLs passed to HTTP clients
   - Check for URL validation and allowlisting
   - Look for internal service URLs that could be accessed via SSRF

4. **Secrets and configuration audit**

   - Search for patterns that look like secrets:
     - API keys: strings matching common key formats
     - Passwords: variables named `password`, `secret`, `token` with hardcoded values
     - Connection strings: database URLs with credentials
   - Check `.gitignore` includes `.env`, secrets files, and key files
   - Verify no secrets in git history (check recent commits for accidental commits)
   - Check that environment variables are used for all sensitive configuration

5. **Data handling audit**

   - Identify where PII (Personally Identifiable Information) is processed
   - Check that sensitive data is not logged
   - Verify data is encrypted at rest and in transit
   - Check for data leakage in error responses (stack traces, internal paths)
   - Verify input validation on all user-facing endpoints

6. **Generate the security report**

## Output Format

```markdown
# Security Audit Report

**Target**: [what was audited]
**Date**: [current date]
**Auditor**: AI-assisted review (manual verification recommended)

---

## Risk Summary

| Severity | Count |
|----------|-------|
| CRITICAL | [N] |
| HIGH     | [N] |
| MEDIUM   | [N] |
| LOW      | [N] |
| INFO     | [N] |

---

## Critical Findings

### SEC-001: [Finding title]
- **Severity**: CRITICAL
- **Category**: [OWASP category]
- **File(s)**: [affected files with line numbers]
- **Description**: [What the vulnerability is]
- **Impact**: [What an attacker could do]
- **Evidence**: [Code snippet or pattern found]
- **Remediation**: [Specific steps to fix]
- **References**: [Relevant CWE, CVE, or documentation links]

---

## High Findings
...

## Medium Findings
...

## Low Findings
...

## Informational
...

---

## Dependency Vulnerabilities

| Package | Severity | CVE | Fix Available | Reachable |
|---------|----------|-----|---------------|-----------|
| [pkg]   | [sev]    | [id]| Yes/No        | Yes/No/Unknown |

---

## Recommendations Summary

### Immediate Actions (This Week)
- [ ] [Critical/high fix]

### Short-Term (This Month)
- [ ] [Medium fixes]

### Ongoing
- [ ] [Process improvements]

---

## Disclaimer

This is an automated security review and does not replace a professional penetration test. Findings are based on static analysis of source code. Runtime behavior, infrastructure configuration, and deployment environment are not covered.
```

## Severity Definitions

| Severity | Criteria |
|----------|----------|
| **CRITICAL** | Directly exploitable, data breach or full compromise likely |
| **HIGH** | Exploitable with some effort, significant data or access at risk |
| **MEDIUM** | Requires specific conditions to exploit, moderate impact |
| **LOW** | Minimal impact or very difficult to exploit |
| **INFO** | Best practice recommendation, no direct vulnerability |

## Error Handling

- **No source code at target path**: Ask the user to confirm the correct path
- **Package manager not detected**: Skip dependency scan, note in report
- **Very large codebase**: Focus on high-risk areas first (auth, API boundaries, data handling)

## Best Practices

- Run security audits before every release and after any auth-related changes
- This audit is a starting point, not a replacement for professional penetration testing
- Address CRITICAL and HIGH findings before deploying to production
- Keep dependencies updated; automate alerts for new advisories
- Pair with `/validate-and-fix` to automatically remediate fixable issues