security-audit

name	security-audit
description	Security audit skill. Use when asked to "audit security", "check for vulnerabilities", "security review", "pentest", or when evaluating code that handles auth, user input, secrets, or external data. Runs a phased scan covering OWASP Top 10 and STRIDE threat modeling.

Security Audit

Phased security scan. Each phase is independent — skip phases that do not apply to the codebase.

Phase 1: Scope

1. Identify the attack surface: what accepts external input? (HTTP endpoints, CLI args, file uploads, WebSocket messages, IPC, environment variables)
2. Identify trust boundaries: where does data cross from untrusted to trusted?
3. List authentication and authorization mechanisms in use
4. Note the deployment model (server, serverless, desktop, CLI)

Phase 2: Input Validation

For each entry point identified in Phase 1:

• Is user input validated and sanitized before use?
• Are SQL queries parameterized (not string-interpolated)?
• Is HTML output escaped to prevent XSS?
• Are file paths validated to prevent path traversal?
• Are file uploads constrained by type and size?
• Is deserialization of untrusted data avoided or sandboxed?

Phase 3: Auth and Session

• Are all protected routes/endpoints checked for authentication?
• Is authorization checked per-resource, not just per-route?
• Are session tokens generated with sufficient entropy?
• Are tokens stored securely (httpOnly, secure, sameSite)?
• Is there rate limiting on login/auth endpoints?
• Are password reset flows safe from enumeration?

Phase 4: Secrets

1. grep -r for common secret patterns in source (API keys, tokens, passwords, connection strings) — exclude node_modules, .git, lock files
2. Check git log --all -p -S "password\|secret\|api_key\|token" for secrets that were committed and later removed (they are still in history)
3. Verify .gitignore covers .env, credential files, and key material
4. Check that secrets are not logged, included in error responses, or exposed in client-side bundles

Phase 5: Dependencies

1. Check for known vulnerabilities: npm audit / pip audit / equivalent
2. Look for unmaintained dependencies (no updates in 2+ years)
3. Check that lockfiles are committed and dependencies are pinned

Phase 6: CI/CD

If CI/CD config exists (.github/workflows/, .gitlab-ci.yml, etc.):

• Are third-party actions/images pinned to SHA, not floating tags?
• Does pull_request_target grant write access to untrusted PRs?
• Are secrets available only to the workflows that need them?
• Can a malicious PR modify CI config to exfiltrate secrets?

Phase 7: STRIDE Threat Model

For each component identified in Phase 1, evaluate:

• Spoofing — Can an attacker impersonate a legitimate user or service?
• Tampering — Can data be modified in transit or at rest without detection?
• Repudiation — Are security-relevant actions logged with enough detail for audit?
• Information Disclosure — Can sensitive data leak through errors, logs, or side channels?
• Denial of Service — Are there unbounded operations an attacker can trigger?
• Elevation of Privilege — Can a low-privilege user reach admin functionality?

Phase 8: Report

For each finding:

1. Severity: Critical / High / Medium / Low / Informational
2. Location: file path and line range
3. Description: what the vulnerability is
4. Impact: what an attacker could do
5. Recommendation: specific fix, not generic advice

Rules

• Only report findings you can point to in the code — no hypotheticals
• If a finding requires a specific runtime condition to exploit, state the condition
• Do not report style issues, linting violations, or non-security code quality as security findings
• Distinguish between confirmed vulnerabilities and potential risks